This does not fix every single edge case.
This only fixes the edge cases for unary operators
on the left hand side of binary operators expecting a variable.
(That probably isn't even every single binary operator or unary operator)
Fixes#179, adds FilePositionMap
This assumes that requested offsets will be close to previous requests,
which should be true if this is used while walking a tree, etc.
Future tasks if the basic design is solid:
- copy license to new files
- Document this in the public API
- Deprecate PositionUtilities or make those APIs use FilePositionMap?
(E.g. cache FilePositionMap in a static variable,
and use $text is === as previous request)
This is incomplete, but still an improvement.
Related to https://github.com/Microsoft/tolerant-php-parser/issues/214
Note: The function never gets TokenKind::StringVarName for
OpenBraceDollarToken (`{$`), so it always uses parseExpression.
Also, TokenKind::Name is already used for parseExpression.
Add test cases for `"${var['stringIndex']}"`, as well of tests for
things tolerant-php-parser already supported due to parseExpression()
stringLiteral16.php was not used due to already being in skipped.json
(bug for making skipped.json specific was filed)
For issues #219 and #214
For https://github.com/Microsoft/tolerant-php-parser/issues/175
Using tolerant-php-parser-to-php-ast,
the following types of statements have been tested,
and the transformed ASTs were identical to nikic/php-ast's AST nodes:
```php
<?php
foo(1234)['index'](true, false);
(new MyClass())();
$result = foo(1234)(5678);
$obj->call('prop')('value');
```
Also, callExpression8.php is valid PHP code.
There shouldn't have been any diagnostics whatsoever.
I'm not very familiar with this repo,
so I might have missed potential bugs.
See https://phpunit.de/manual/current/en/risky-tests.html
I'm using php 7.2.2, and phpunit 6.5.6 gets installed.
I believe that the newer phpunit releases were stricter by default about
tests that don't perform any assertions
E.g. if something using tolerant-php-parser is using DiagnosticKind,
but class diagnostic isn't loaded yet,
then I might fail to load this class.
(If the standard PSR-4 loading rules are used instead of an optimized autoloader)
Add a simple benchmarking script
Extreme optimization, sacrificing code style in some areas.
- This is meant for discussion, since the project is
in the optimization phase.
This commit reduces the time needed to getDiagnostics
from 0.013 to 0.007 seconds.
Average time to generate diagnostics (before): 0.013...
Average time to generate diagnostics (after): 0.006921
time to parse (Without diagnostics): 0.036374
(E.g. getDiagnostics previously took 36% of the time compared
to generating an AST,
and now it takes 19% of that time.)
Previously, all of the following examples would produce parse errors,
while being valid PHP code:
- new static;
- new static::$a;
- if ($a instanceof static) {}
This commit takes care of these edge cases.
and a faster version of eatOptional().
eat() is called frequently when converting lexed tokens to values,
and often with a single token type. Varargs and array counting would
slow that down.
validatiion/ParserPerformance sped up from 0.581 to 0.574 seconds (1%).
(Added a loop to run on 100 files 10 times, divided by 10, took best times)