User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:22.214.171.124) Gecko/20080201 Firefox/126.96.36.199 Build Identifier: I met a compilation error on nsDOMClassInfo.cpp file when I turned off the JS_THREADSAFE. The reason is that nsWindowSH::AddProperty function can't use the struct JSScopeProperty. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 306888 [details] [diff] [review] v1 As mentioned in the bug 412985 comment 27, I modified the patch by considering jason's comment. In jslock.h file, I can't move "#include "jsscope.h" to top of the file. Because, If #include "jsscope.h" is moved so, the struct JSScope in jsscope.h can't access struct JSThinLock. So, I moved #include "jsscope.h" to out of #ifdef JS_THREADSAFE ~ #endif as the patch. I'd like to get an advice about this patch.
Comment on attachment 306888 [details] [diff] [review] v1 Now that JSTitle has been factored from JSScope, could we not get rid of the #include cycle between jslock.h and jsscope.h, by having jslock.h *not* include jsscope.h conditionally any longer? This would be great. Any dependent files that want both jslock.h and jsscope.h would have to #include both. That may already be satisfied by current #includes. /be
(In reply to comment #2) Looks like removing the #include "jsscope.h" from jslock.h and adding it to jscntxt.h works. The latter is necessary because of another cycle: the macros OBJ_GET_SLOT and OBJ_SET_SLOT, defined in jsobj.h, require OBJ_SCOPE and struct JSScope from jsscope.h, which includes jsobj.h. jscntxt.h was previously getting jsscope.h anyway, via jslock.h via jsatom.h.
Better to reduce nesting. Macros do not expand until called, so if there are only a few, or ideally no, calls that occur in files that do not include jsscope.h, then why not avoid nesting #include "jsscope.h" anywhere? Currently AFAICT it is nested only in jslock.h. /be
Created attachment 307312 [details] [diff] [review] v2 Here's an updated patch. Gyu-young, please check that this works for you. I built the browser with this patch, but I didn't try to build it without JS_THREADSAFE. (I did build js shell both ways.)
Created attachment 307323 [details] [diff] [review] alternative patch avoids over-including Sorry, this was my old mess. I'll clean it up if you agree with this approach. Thanks, /be
Comment on attachment 307323 [details] [diff] [review] alternative patch avoids over-including Yes.
This is a safe change to header file and #ifdef relations, wanted by Samsung. It can go in ASAP without rocking any boats. /be
Comment on attachment 307323 [details] [diff] [review] alternative patch avoids over-including Bug should not be a blocker, patch just wants approval. /be
Fixed: js/src/jsatom.h 3.83 js/src/jsexn.c 3.99 js/src/jslock.h 3.42 js/src/jsnum.c 3.110 js/src/jsregexp.c 3.190 js/src/jsstr.c 3.198 /be
It seems this caused: c:\slave\trunk_2k3\mozilla\js\src\xpconnect\src\xpcinlines.h(746) : error C3861: 'ID_TO_VALUE': identifier not found c:\slave\trunk_2k3\mozilla\js\src\xpconnect\src\xpcinlines.h(746) : error C3861: 'ID_TO_VALUE': identifier not found NEXT ERROR make: *** [nsXPConnect.obj] Error 2 make: *** Waiting for unfinished jobs.... c:\slave\trunk_2k3\mozilla\js\src\xpconnect\src\xpcinlines.h(746) : error C3861: 'ID_TO_VALUE': identifier not found
Created attachment 307508 [details] [diff] [review] v1 I think Brendan patch can take place a compilation error. As mentioned in Mr. Bukanov, xpcinlines.h can't use an ID_TO_VALUE macro provided by jsscope.h. (With the Firefox 3.0 beta 3, I want to test it with the latest firefox but I can't because of some compilation errors in other module) In order to solve this problem, I added #include “jsscope.h” to a xpcprivate.h. Because, Xpcinlines.h included jsscope.h through a xpcprivate.h that has a jscntxt.h. but, a jscntxt.h doesn’t include a jsscope.h any longer.
I moved ID_TO_VALUE to jsprvtd.h right under the *JSID* macros (it really should be named like them, but later). Please update your tree and re-test. /be
Comment on attachment 307508 [details] [diff] [review] v1 Should not be necessary, is not in a threadsafe build. If a single-threaded (JS_THREADSAFE not defined) build has some problem(s), please show the failing make's output. Thanks, /be
I think the building firefox without JS_THREADSAFE is left modification of XPConnect. So,I reported a bug for this problem. Bug 421481 – XPConnect can't be built without JS_THREADSAFE.