Currently compiling SpiderMonkey with JS_HAS_GENERATORS defined as 0 leads to compilation errors in jsiter.c. This has to be fixed as this is a supported configuration.
Igor, if you could take this one, my head would be less explode-y. Thanks,
Created attachment 239259 [details] [diff] [review]
Changes to allow to compile/run without JS_HAS_GENEARATORS:
1. JSOP_STARTITER and JSOP_ENDITER should be available even if !JS_HAS_GENEARATORS.
2. Almost all of iterator-related code must be available even if !JS_HAS_GENEARATORS.
Clearly with extra efforts it would be possible to shrink !JS_HAS_GENEARATORS, but I do not think it worths it.
Moreover, after the patch the only part of the iterator code that is inside JS_HAS_GENEARATORS-only section is the definitions of Iterator constructor and self functions. Thus I suggest to always provide full Iterator code including constructor declaration even with !JS_HAS_GENEARATORS.
This would cleanup the meaning of JS_HAS_GENEARATORS to stand just for generator and array comprehension support.
Created attachment 239260 [details] [diff] [review]
An alternative version that just makes full iterator support available even with !JS_HAS_GENERATORS. I like it much better then v0.
Created attachment 239262 [details] [diff] [review]
This is just v1 with fixed comments to reflect the reality after the patch.
Comment on attachment 239262 [details] [diff] [review]
Thanks -- I have the jsinterp.c change in my tree already, hacked it the other day as I was passing by.
We should figure link these bugs to the js1.7 bug, so we don't miss anything that wasn't fixed1.8.1.
I committed the patch from comment 4 to the trunk:
Checking in jsinterp.c;
/cvsroot/mozilla/js/src/jsinterp.c,v <-- jsinterp.c
new revision: 3.292; previous revision: 3.291
Checking in jsiter.c;
/cvsroot/mozilla/js/src/jsiter.c,v <-- jsiter.c
new revision: 3.42; previous revision: 3.41
Ability to compile without generator support is a feature which is desirable in JS 1.7.
As this is blocking188.8.131.52+, please either request approval184.108.40.206 on the
current patch or, if needed, attach a branch version of the patch and request
approval220.127.116.11 on it.
The committed patch for 1.8.1 from bug 354982 already addressed this.