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

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P2)

Description

[Ed Morley [:emorley]]

Inbound tip Windows spidermonkey-warnaserrdebug opt & debug builds are busted:
https://tbpl.mozilla.org/php/getParsedLog.php?id=13941508&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=13941510&tree=Mozilla-Inbound

Last green changeset:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&noignore=1&jobname=mozilla-inbound_win32-debug_spidermonkey-warnaserrdebug&rev=ed582ea30746

First broken:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&noignore=1&jobname=mozilla-inbound_win32-debug_spidermonkey-warnaserrdebug&rev=630e9fa1dd0b

Range:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ed582ea30746&tochange=630e9fa1dd0b

(Though I'm sure more has broken since the initial range, whilst the builds have been busted).

Comment 1

[Andrew McCreight [:mccr8]]

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

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

is this still an issue? If yes, and no imminent fix, can we disable these jobs to save compute time?

Comment 3

[Jeff Walden [:Waldo]]

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...

Comment 4

[Ed Morley [:emorley]]

(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.

Comment 5

[Flavio]

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.

Comment 6

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

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?

Comment 7

[Ed Morley [: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.

Comment 8

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(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?

Comment 9

[Phil Ringnalda (:philor)]

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.

Comment 10

[Chris Peterson [:cpeterson]]

Waldo volunteered to fix Windows warnings-as-errors at the JS work week:
https://etherpad.mozilla.org/JSWorkWeek-windows

Comment 12

[Ed Morley [:emorley]]

Mass-closing old bugs I filed that have not had recent activity/no longer affect me.