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
In preparation for merging $push and $pop into it as well, so
that the state changes that happen for a particular state/type
are declared in the same place.
Bug: T201606
Change-Id: Idd12786d625621af949e7e6487e4c1655f61f295
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
* Group related operators and token types together.
* Document what each group's members have in common for the purposes of
parsing and the state machine.
* Add spec reference.
Also confirmed that each group matches the spec (nothing missing,
nothing extra).
Bug: T201606
Change-Id: I9128beed9ab5dcf831d4655854565f826f81c602
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Follows-up 93b8023946.
The $wgResourceLoaderMinifierMaxLineLength config var was deprecated
in MediaWiki 1.27. The parameter of minify() was not used by other
code, and no new usage has been introduced since then, either.
Remove the feature from JavaScriptMinifier, and add a release note.
The 1.31 release notes already contain a note about the removal
of the configuration variables.
The feature was not covered by unit tests.
Change-Id: I38eb4187e3a8e2d882f317481b43f0bf6ac3bada
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
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
I can see that "parent::__construct" literally calls the parent
constructor. I can see that stuff preceeded by the keyword "protected"
is protected. I really (really) don't need comments explaining such.
Change-Id: I7458e714976a6acd3ba6a7c93fdc27d03903df83
The $wgResourceLoaderMinifierStatementsOnOwnLine config var was deprecated
in MediaWiki 1.27. The parameter of minify() was not used by other code, and
no new usage has been introduced since then, either.
Remove the feature from JavaScriptMinifier, and add a release note for that.
The same 1.31 release notes also contain a note already about the removal
of the configuration variable.
The feature was not covered by unit tests.
The following private variables have been removed, that are no longer used
due to this change: $newlineBefore, $newlineAfter, $newlineAdded.
Change-Id: I2cbf271156c1954abb982531d0125b4b9573b12c
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
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
This broke the OpenLayers support in the Maps extension, as used for example on TranslateWiki.net.
The original JavaScriptMinifier's tokenizer (r83885) explicitly didn't bother looking for the exponent part because it "didn't matter" to its internal state machine; however since r83891 added a max line length that definitely is not true.
I've split out handling of hex and decimal numerals, and let the decimal numeral handling check for exponents.
PHPUnit test cases were added in r103846.
