391423 - Reposition JS_(BEGIN|END)_EXTERN_C to avoid nesting #includes

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Ed Lee :Mardak]

Attachment: hg/actionmonkey patch

This causes problems for MMgc and C++ stuff that end up in extern "C" {} blocks.

Attached is a patch for hg/actionmonkey, but the idea would work on trunk as well.

Comment 1

[Ed Lee :Mardak]

Attachment: cvs v1

Comment 2

[Ed Lee :Mardak]

Comment on attachment 275830 [details] [diff] [review]
cvs v1

The patch works for hg/actionmonkey w/ MMgc, but the minimal changes needed is the following:

>+++ js/src/jslock.h	8 Aug 2007 20:17:10 -0000
>@@ -107,17 +107,19 @@ typedef struct JSFatLockTable {
> /*
>  * Include jsscope.h so JS_LOCK_OBJ macro callers don't have to include it.
>  * Since there is a JSThinLock member in JSScope, we can't nest this include
>  * much earlier (see JSThinLock's typedef, above).  Yes, that means there is
>  * an #include cycle between jslock.h and jsscope.h: moderate-sized XXX here,
>  * to be fixed by moving JS_LOCK_SCOPE to jsscope.h, JS_LOCK_OBJ to jsobj.h,
>  * and so on.
>  */
>+JS_END_EXTERN_C
> #include "jsscope.h"
>+JS_BEGIN_EXTERN_C
> 
> #define JS_LOCK_RUNTIME(rt)         js_LockRuntime(rt)
> #define JS_UNLOCK_RUNTIME(rt)       js_UnlockRuntime(rt)

Comment 3

[Jason Orendorff [:jorendorff]]

It'd be nice to get this patch into trunk.  I'd be happy if you could check the minimal change into actionmonkey, though.  We need it: Firefox won't even build in actionmonkey right now.  And I think if an identical change later comes downstream from trunk, hg will merge correctly without protest.

Comment 4

[Ed Lee :Mardak]

Can someone check this in to cvs? I'll merge hg/cvs-trunk-mirror to hg/mozilla-central then that to hg/actionmonkey.

Comment 5

[Jeff Walden [:Waldo]]

In on trunk.

Comment 6

[Ed Lee :Mardak]

Thanks waldo for checking in to cvs.
I've pulled to hg/mozilla-central changeset 4486:  	db456f3a9ed8
and merged into hg/actionmonkey changeset 4519:  	db456f3a9ed8