Closed Bug 778469 Opened 12 years ago Closed 6 years ago

Fix Windows spidermonkey-warnaserrdebug builds & re-enable them on inbound

Categories

(Core :: JavaScript Engine, defect, P2)

x86
Windows 7
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: emorley, Assigned: Waldo)

References

Details

(Whiteboard: [js:t])

This is the warning:

jsanalyze.cpp

e:\builds\moz2_slave\m-in-w32-dbg-spidermonkey-warnaserrdebug\src\js\src\jsinferinlines.h(313) : error C2664: 'js_GetClassPrototype' : cannot convert parameter 4 from 'JS::RootedObject *' to 'JS::MutableHandleObject'

        No constructor could take the source type, or constructor overload resolution was ambiguous

e:\builds\moz2_slave\m-in-w32-dbg-spidermonkey-warnaserrdebug\src\js\src\jsinferinlines.h(606) : error C2664: 'js_GetClassPrototype' : cannot convert parameter 4 from 'JS::RootedObject *' to 'JS::MutableHandleObject'

        No constructor could take the source type, or constructor overload resolution was ambiguous

e:\builds\moz2_slave\m-in-w32-dbg-spidermonkey-warnaserrdebug\src\js\src\jsobjinlines.h(922) : error C2664: 'JSObject::lookupGeneric' : cannot convert parameter 3 from 'JS::RootedObject *' to 'JS::MutableHandleObject'

        No constructor could take the source type, or constructor overload resolution was ambiguous

e:\builds\moz2_slave\m-in-w32-dbg-spidermonkey-warnaserrdebug\src\js\src\jsobjinlines.h(1164) : error C2664: 'JSObject::lookupGeneric' : cannot convert parameter 3 from 'JS::RootedObject *' to 'JS::MutableHandleObject'

        No constructor could take the source type, or constructor overload resolution was ambiguous
Summary: Tinderbox Windows spidermonkey-warnaserrdebug builds busted for 3 weeks → Tinderbox Windows spidermonkey-warnaserrdebug builds busted for 7 weeks
Blocks: 785798
Whiteboard: [js:t]
is this still an issue? If yes, and no imminent fix, can we disable these jobs to save compute time?
I think someone turned them off already, and never bothered to close this bug somehow.  Now, I *would* like to reenable them (I think I cleaned up all the errors once, but I couldn't be certain as these builds had been disabled), but that's probably an issue for another bug...
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #3)
> I think someone turned them off already, and never bothered to close this
> bug somehow.  Now, I *would* like to reenable them (I think I cleaned up all
> the errors once, but I couldn't be certain as these builds had been
> disabled), but that's probably an issue for another bug...

It wasn't a case of 'someone never bothered' - this is the bug to fix them, bug 785798 (which this is marked as blocking) is where they were turned off.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Tinderbox Windows spidermonkey-warnaserrdebug builds busted for 7 weeks → Fix Windows spidermonkey-warnaserrdebug builds
Summary: Fix Windows spidermonkey-warnaserrdebug builds → Fix Windows spidermonkey-warnaserrdebug builds & re-enable them on inbound
I've been having this issue with SeaMonkey in versions 2.13 and 2.13.1 using VS2005. The easiest solution, for the moment, is to build using cl.exe and other tools from VS2008. Building on VS2010 works too.
Found in triage. Its been over a year since last update, and we've updated compiler/toolchain a bunch since then. 

Anything still to do here? If these tests are working again, have they been re-enabled?
Flags: needinfo?(emorley)
(In reply to John O'Duinn [:joduinn] from comment #6)
> Anything still to do here? If these tests are working again, have they been
> re-enabled?

I have no idea, they are not running at present and I'm not the owner of them.
Flags: needinfo?(emorley)
(In reply to Ed Morley (PTO 18th Dec until 2nd Jan) [:edmorley UTC+0] from comment #7)
> (In reply to John O'Duinn [:joduinn] from comment #6)
> > Anything still to do here? If these tests are working again, have they been
> > re-enabled?
> 
> I have no idea, they are not running at present and I'm not the owner of
> them.

:ed ok, I only asked as you were original filer, and I dont know sheriff process for re-enabling tests after they've been repaired.

:mrbkap, :sphink, anything left to do here?
Flags: needinfo?(sphink)
Flags: needinfo?(mrbkap)
Everything is left to do here.

Here's what has to happen:

0. Someone wants this build to be run so badly that they'll take on complete and never-ending responsibility for fixing it when other people break it, because it will not be tier-1, and everyone who breaks it will say "I don't even *have* Windows, could you fix that for me?"
1. That person fixes all the built-up warnings on their compiler.
2. That person gets a loaner and fixes any that show up there but not locally.
3. That person files a releng bug to get the build turned back on.
4. This bug is closed.
5. Over and over and over, I haunt that person about bustage on bustage on bustage.
6. They quit.
7. I turn it back off.

The steps are a little less certain toward the end, but they are very clear at the start. This is a jsengine bug, about someone (who will be annoyed about how close their birthday is to Christmas, because they will have to have been born yesterday) making a huge open-ended commitment and also making changes to jsengine code. There will be releng bugs after that person exists, but this ain't one of them.
Status: REOPENED → NEW
Flags: needinfo?(sphink)
Flags: needinfo?(mrbkap)
Waldo volunteered to fix Windows warnings-as-errors at the JS work week:
https://etherpad.mozilla.org/JSWorkWeek-windows
Assignee: general → jwalden+bmo
Priority: -- → P2
Mass-closing old bugs I filed that have not had recent activity/no longer affect me.
Status: NEW → RESOLVED
Closed: 12 years ago6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.