enable e4x in JS components

RESOLVED FIXED in mozilla1.8alpha6

Status

()

defect
P1
normal
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: shaver, Assigned: shaver)

Tracking

({js1.5})

Trunk
mozilla1.8alpha6
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

For the win, as it were.
Caveat: don't use eval("e4x-using-script") in your components.
Attachment #169407 - Flags: review?(brendan)
Comment on attachment 169407 [details] [diff] [review]
enable JSOPTION_XML during compilation

Cool -- can you hold this bug open and I'll patch the engine to propagate
options along with version so that compiled scripts and functions can eval
freely?

/be
Attachment #169407 - Flags: review?(brendan) → review+
See the comments in jscntxt.h for the subtle implications.  No need to rev the
script XDR magic number, or the XUL FastLoad file version, because existing
XDR'ed scripts have a version number without the JSVERSION_HAS_XML flag set. 
Zero high order bits => forward compatibility.

/be
Assignee: shaver → brendan
Status: NEW → ASSIGNED
Attachment #169452 - Flags: review?(shaver)
A typo fix and rewording in the last paragraph of that big jscntxt.h comment:

 * Note also that script->version must contain this XML option flag in order
 * for XDR'ed scripts to serialize and deserialize with that option preserved
 * for detection at run-time.  We can't copy other compile-time options into
 * script->version because that would break backward compatibility (certain
 * other options, e.g. JSOPTION_VAROBJFIX, are analogous to JSOPTION_XML).

/be
Keywords: js1.5
Priority: -- → P1
Target Milestone: --- → mozilla1.8alpha6
Attachment #169452 - Flags: review?(shaver) → review+
This avoids adding JSVERSION_MASK and JSVERSION_HAS_XML to jspubtd.h, which is
part of the public API.  So JS_SetVersion asserts that its version argument is
a well-defined version number (not unknown, no high-order flag bits).  It's a
pretty mechanical change to the last patch, so I'm imputing r=shaver.

/be
Attachment #169452 - Attachment is obsolete: true
Attachment #169479 - Flags: review+
I checked in, so this goes back to shaver ;-).

/be
Assignee: brendan → shaver
Status: ASSIGNED → NEW
I checked in shaver's patch (attachment 169407 [details] [diff] [review]), so this bug is fixed.

/be
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.