[This is a spin-off of bug 386265 comment 41] JS_IS_VALID_TRACE_KIND still refers to removed JSATOM_TRACE with !JS_HAS_XML_SUPPORT.
Created attachment 276515 [details] [diff] [review] v1 The patch fixes JS_IS_VALID_TRACE_KIND macro and adds a static assert to prevent this kind of bugs to happen again.
I checked in the patch from comment 1 to the trunk: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=%2Fcvsroot&date=explicit&mindate=1187036463&maxdate=1187036702&who=igor%25mir2.org
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Based on Tinderbox it looks like this could have caused the Win32 orangeness. Any thoughts?
(In reply to comment #3) > Based on Tinderbox it looks like this could have caused the Win32 orangeness. Sorry for not waiting until all the boxes finish the tests. My assumption was that adding an extern declaration of a C function that was never accessed from the code (this is what JS_STATIC_ASSERT expands into) may only affect the compilation. So I just waited until one of Linux/Max/Win boxes finished. The next time I should to take such shortcuts and wait for all tests to finish for the reason related to the the last orange. If orange happens during my commit, I better be available to help to figure out the reason for it like explaining the nature of the check in.
You need to log in before you can comment on or make changes to this bug.