decoder reported this on IRC. The problem was that the call to getOrCreateScript in IonBuilder was not propagating an error. This patch refactors the inlining code a bit so that this is handled correctly. This may fix intermittent orange bug 939714 and/or bug 923614.

Forgot to add the testcase.

Comment on attachment 8341804 [details] [diff] [review] Patch Review of attachment 8341804 [details] [diff] [review]: ----------------------------------------------------------------- Nice. We indeed need to have some error propagation there. Though I have a few comments: 1) Why don't we reuse InliningStatus, instead of adding InliningDecision. I don't see any reason not to. They both have the same 3 values (error, inlined, notInlined). No need for this extra enum. Though I wouldn't be mad if we decided to rename InliningStatus to InliningDecision ;) 2) IonBuilder::DontInline should be IonBuilder::dontInline(targetScript, const char *reason). Lowercase. Looks much cleaner with the dontInline spewing ;) Ps: did you have to do this before optimizationLevels landed :P

https://hg.mozilla.org/integration/mozilla-inbound/rev/48b19f9cc967 (In reply to Hannes Verschore [:h4writer] from comment #2) > 1) Why don't we reuse InliningStatus, instead of adding InliningDecision. Discussed this on IRC - it felt wrong to use "InliningStatus_Inlined" when we are not sure we are going to inline.. > > 2) IonBuilder::DontInline should be IonBuilder::dontInline(targetScript, > const char *reason). Lowercase. It's a static method so it has to be uppercase - see also MBasicBlock::New, IonBuilder::TableSwitch, etc. > Ps: did you have to do this before optimizationLevels landed :P Sorry! For some reason we're touching the same code lately :(