The following pattern of input (found in jquery.js) triggered
this bug:
call( {
key: 1 ? 0 : function () {
return this;
}
} );
The open brace changes state to PROPERTY_ASSIGNMENT (for object literals).
The colon after 'key' sets state to PROPERTY_EXPRESSION.
Each individual parts of an expression (identifiers and literal values)
is recognised with state *_EXPRESSION_OP, such as PROPERTY_EXPRESSION_OP.
The '1' after 'key:' correctly sets the state to PROPERTY_EXPRESSION_OP.
Upto there it goes well, but after that it goes wrong.
The question mark (TYPE_HOOK) in this context was wrongly switching
back to PROPERTY_EXPRESSION. That is a problem because that does not
handle TYPE_COLON, which meant '0: function' was seen together as a
sequence of continuous PROPERTY_EXPRESSION_OP where TYPE_FUNC may
not be handled.
Fixed by changing handling of TYPE_HOOK in PROPERTY_EXPRESSION to
switch states to EXPRESSION_TERNARY, and also performing a push
so that ternary handling can pop back to the property expression.
This mirrors the handling that already exists for ternaries in
the regular handling of EXPRESSION/EXPRESSION_OP (as opposed to
the variant for object literal properties).
Bug: T201606
Change-Id: I6104c839cfc3416257543b54a91b74cb4aa4193b
Discovered by adding a test case that uses file_get_contents()
to pass jquery.js, and then scan the PHPUnit output for an entry
containing `return` by itself on a line where the next line
is isn't `;` - then reducing it to a test case as small as possible.
This was reduced from the definition of jQuery.event.addProp.
Bug: T201606
Change-Id: I1f907436c32630102e60e3ded7092dbeb9669fe8
Previously, $push contained:
self::PROPERTY_EXPRESSION_OP => [
self::TYPE_PAREN_OPEN => self::PROPERTY_EXPRESSION_OP
],
But $pop contained:
self::PROPERTY_EXPRESSION_OP => [ self::TYPE_BRACE_CLOSE => true ]
This meant that when a closing brace was found inside a property
expression, it would wrongly pop the stack, eventhough we are still
inside the property expression.
The impact is that everything after this is one level higher in
the stack than it should be, causing various other types to be
misinterpreted. Including in the following contrived example:
call( function () {
try {
} catch (e) {
obj = {
key: 1 ? 0 : {} // A
}; // B
} // C
return name === 'input';
} );
In the above, the closing brace at A would close the 'obj.key' assignment
(PROPERTY_EXPRESSION_OP), instead of waiting for the closing brace at B to
decide that.
Then the closing brace at B would wrongly close the 'catch' block (instead of
the 'obj' assignment). And lastly, the closing brace at C would close the
function body (STATEMENT).
This resulted in keyword 'return' being interpreted while in state
PAREN_EXPRESSION_OP instead of STATEMENT, where PAREN_EXPRESSION_OP is the
arguments list to `call()`. In an argument list, TYPE_RETURN is not valid,
which means we stay in that state, instead of progressing to EXPRESSION_NO_NL,
which then wrongly allows for a line break to be inserted.
Bug: T201606
Change-Id: I07b809a7ca56e282ecb48b5c89c217b4b8da6856
Set maxLineLength to '1' instead of messing with filler content.
This makes it easy to see all potential line-breaks, instead of only
at the 999th offset.
Bug: T201606
Change-Id: I220b145c5bc8e7d1a41efacd2a6cea738545f006
When parsing an incomplete string literal or regex literal at the end of a file,
$end would be set to an offset higher than $length, because the code
speculatively increases $end without correcting for this scenario.
This is due to the assumption that the strcspn() search will end because
an end character was seen, instead of simply ending because the string
doesn't have any further characters.
Bug: T75556
Change-Id: I2325c9aff33293c13ff414699c2d47306182aaa6
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
Fix-up for I5ab29b686b8. If we encounter stupid code like
`a.true = 1;` or `a = { true: 1 }`, we should not convert that to !0/!1.
Because JSMin barfs on such input, it is necessary to add another parameter to
the test method which specifies whether or not the minified JavaScript is
supposed to be valid JavaScript by the standards of JSMin.
Change-Id: Ib78c628147fdb95982d6e33e0ab298584fb63d0b
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
* Per https://bugzilla.wikimedia.org/show_bug.cgi?id=27395#c1
adding test cases for things that broke in the past:
- bug 26931
- bug 27046
* Added various other small tests that seem fitting in their context
* Moved testBug32548Exponent to below the data provider (like most
other tests iirc).
Change-Id: I7a4df097108ec05bc58d5a110329e13ff9587c8a
r103915 added a parse error for 'more than 2 decimal points' in a number; this is the wrong place to check for that. Should only check whether there's more digits or identifier chars -- identifier chars would be illegal.
Added test cases for the exponent missing fails, tweaked it to be more consistent (only need to check for one e; if we have more we can lump them in with 'not digits' :)
Also cleaned up no-longer-needed suppress/restore warnings around JS parser invocation
This will trigger 2 test failures, where an exponent in a JS numeric literal gets split over line breaks at the '-' or '+', causing a parse error in the resulting output.
A number with the same string length but without using + or - in the exponent passes through fine, indicating that it's the -/+ that's getting misinterpreted.
Followup r91591, r93020: patch to jsminplus to support Unicode chars and char escapes in identifiers
Fast-path check keeps runtime about the same on most scripts (eg jquery.js parsing was abround 4100ms both before and after on my test machine)
Slow-path code kicks in if plain ASCII word chars don't extend all the way to the next whitespace or punctuation char.
Using PCRE's Unicode properties magic to ensure that we're catching everything, following ECMA-262 edition 5.1 spec.
Note that identifiers using escapes don't get normalized to their UTF-8 form; this might be a nice thing to do as it saves a couple bytes, but currently there's no change made to output.
Added QUnit tests to verify that unicode letter & escapes work in identifiers in all supported browsers (ok back to IE 6, yay)
