2. Removal of Codegen.superClassSlashName field since Codegen.superSlashName since it is never used as a part of a signature and ClassFileWriter converts . into / in type name automatically.
- call the JSRuntime's checkObjectAccess callback, if configured, for each
get or set that invokes a user-defined function (a user-defined function is
a scripted or native function object, not a native JSPropertyOp C function).
The value passed as an in-out parameter in *vp is the function object, so
the callback could, e.g., clone function objects and configure them with
different parent objects, if that helped import them into a trust domain.
- Fix a long-standing bug that broke the deprecated, old-style, and rarely-
used top-level getter/setter function declaration form:
getter function f() { return ++x; }
setter function f(y) { return x = y; }
We want js_CheckRedeclaration to complain only if a permanent getter is
being redefined by another getter, likewise for a setter -- but not when
(as above) a setter is being added to a top-level object for the same id
as a pre-existing getter (or vice versa).
- call the JSRuntime's checkObjectAccess callback, if configured, for each
get or set that invokes a user-defined function (a user-defined function is
a scripted or native function object, not a native JSPropertyOp C function).
The value passed as an in-out parameter in *vp is the function object, so
the callback could, e.g., clone function objects and configure them with
different parent objects, if that helped import them into a trust domain.
- Fix a long-standing bug that broke the deprecated, old-style, and rarely-
used top-level getter/setter function declaration form:
getter function f() { return ++x; }
setter function f(y) { return x = y; }
We want js_CheckRedeclaration to complain only if a permanent getter is
being redefined by another getter, likewise for a setter -- but not when
(as above) a setter is being added to a top-level object for the same id
as a pre-existing getter (or vice versa).
in js_FoldConstants where it was added (suboptimally: it worked, but it ran
so late that js_FoldConstants recursion was not reduced, only js_EmitTree
recursion), to NewBinary, where it avoids JSParseNode allocations up front
and reduces recursion in all parse-tree walking.
- This change enables js_FoldConstants to see a very long concatenation of
string literals as a PN_LIST node, so it can quickly concatenate without
running afoul of O(n^2) problems inherent in js_ConcatStrings applied to
two atomized strings (the old way of folding string concatenations, still
used for any pairwise string literal concatenation).
- Further optimize the first change for the second by having NewBinary set a
new pn_strcat flag (overlaying the pn_extra field) of the PN_LIST arm of
the JSParseNode.pn_u union, whenever it sees at least one string literal in
a concatenation that might be folded (whose operands might all be constants
of string or number type).
- Notes:
- only string and number constants are folded (not boolean or null
constants);
- only all-constant left-associated binary expression chains are folded,
so 2 * foo * 3 is not folded using commutativity of * over numbers, nor
is "hi" + " there" + foo folded to "hi there" + foo.
- gcc3.2 -O and objdump -x say I added 708 bytes of instructions with this
change. I tried to keep it down to what was necessary for common script;
I don't think JS needs an optimizing-compiler-strength constant folder,
and I don't think this 1K bloat is too high a price to pay for this fix.
But I'll certainly work on reducing footprint elsewhere, if I can.
- Bug 174341, r=shaver.
Attempts to access/modify properties of null or undefined are explicitly checked to include in error messages the property name so it would be possible on error in x.y.z to know if it is x or y that was undefined or null.
Inspired by suggestion from Russell Gold.
I also added explicit flags to Parser: languageVersion and allowMemberExprAsFunctionName and set them from Context. In this way Parser can be used without Context which is useful for debugging.
1. It is not passed as a parameter to Interpreter/Codegen, instead Codegen access it directly when necessary.
2. ClassNameHelper.reset method is removed as inherently thread unsafe and data that should be used during compilation of single script is stored in Codegen itself.
3. Instead of a special DefaultClassRepository null is used to indicate that generated classes should not be stored and JavaAdapter is modified to take ClassRepository as a parameter, not ClassNameHelper.
PreorderNodeIterator iter = new PreorderNodeIterator();
for (iter.start(tree); !iter.done(); iter.next()) {
Node node = iter.getCurrent();
...
}
instead of
PreorderNodeIterator iter = tree.getPreorderIterator();
Node node;
while ((node = iter.nextNode()) != null) {
}
to allow for more flexible usage and added PreorderNodeIterator.nextSkipSubtree to skip iteration of the last visited node subtree which allows to have simple code in Optimizer.buildStatementList when iterating over statements.
The bug caused by a missed check in StmtNodeIterator.nextNode for a possible null result of findFirstInterestingNode inside the search loop which made search to stop preliminary with non-empty stack.
The changes fixe this and integrate StmtNodeIterator into
Optimizer.buildStatementList as StmtNodeIterator was used only by
buildStatementList and the new version is simpler.
The reason for the bug was that omj/optimizer/Optimizer.java when optimizing code for this[name] (see GETELEM switch, line 665) assumed a number context for GETELEM index node unconditionally which is wrong.
The fix uses number context only if [] argument is known for sure to be a number.
The bug was caused by a double call to Codegen.addNumberConstant, the first
time correctly from Codegen.visitLiteral and the second time wrongfully from
the loop in emitConstantDudeInitializers where loop index should be used
instead of calling addNumberConstant. As addNumberConstant would return the
same index for same numbers, the bug surfaces only with NaN as
addNumberConstant does not recognizes already added NaN. The bug also visible
only with optimization set to 1 or higher since only then constant folding can
produce NaN literal.
The fix removes the second call to addNumberConstant and uses
ScriptRuntime.NaNobj for NaNs.
The reason for the bug is that emitDirectConstructor generates code to call
setPrototype twice instead of setPrototype/setParentScope pair during new JS
object construction. The fix replaces that setup by a single call to
BaseFunction.createObject which is used by Interpreter as well.
brendan%mozilla.org
dbradley%netscape.com
igor%mir2.org
cls%seawood.org
seawood%netscape.com
jrgm%netscape.com
dougt%netscape.com
timeless%mozdev.org
pschwartau%netscape.com
mkaply%us.ibm.com
mstoltz%netscape.com
locka%iol.ie