E.g. `unset($x)/2` is a syntax error.
Previously, this parser would not treat that as a syntax error.
This is similar to how `echo` can only be used as a top level statement.
- Tools using this parser may expect `unset` only as a top level statement
See
https://secure.php.net/manual/en/function.unset.php#refsect1-function.unset-notes
The included test files can be executed.
They will always print the inline HTML,
indicating that PHP is doing the equivalent of inserting semicolons.
Fixes#246
Also, ignore temporary files created by vim
Before, tolerant-php-parser parsed the tokens after `<?=` and `<?php`
the same way.
Fixes#220 (This commit and subsequent commits in this PR)
This adds `TokenKind::ScriptSectionStartWithEchoTag` and handles the
subsequent tokens differently if that token kind is seen instead of
`ScriptSectionStartTag`.
This reuses `ExpressionStatement` with an `EchoExpression` for simplicity.
The resulting expression will have no `echoKeyword` because
`<?=` was part of the preceding `InlineHTML` Node.
- In all cases that I'm aware of,
the ExpressionStatement with the EchoExpression will be moved
into the outer statement list.
NOTE: echo is a statement, not an expression.
It must be followed by `?>` or `;`
- `echo exprList` can't be used as an expression.
- Contrast with `print expr`, (`PrintIntrinsicExpression`),
which is correctly treated as an expression.
Update documentation
Add a test that the Parser will warn about `<?= 'expr'<EOF>`.
- Fixing that bug got rid of an incorrect EmptyExpression in another test
(programStructure5.php.tree)
Add a new array `otherQualifiedNameList` alongside qualifiedName
to `CatchClause`. (Contains remaining `Token`s and `QualifiedName`s)
(This design breaks backwards compatibility as little as possible)
- A future backwards incompatible release should merge the two
properties into `qualifiedNameList`,
or something along those lines.
Add a new helper method to parse the catch list.
- The new helper is required because
`tests/cases/php-langspec/exception_handling/odds_and_ends.php`
should not fail because `catch (int $e)` is **syntactically** valid php
(in 7.x), i.e. `php --syntax-check` doesn't reject it.
Do this in a way that makes it less likely that applications already
using targetName will throw an exception or error.
This should be revisited in a future backwards incompatible release.
Add remainingTargetNames as a new property.
NOTE: traits16.php is invalid php 7 code,
so traits16.php.diag should be non-empty.
However, tolerant-php-parser emits a slightly different error
message than `php -l` would.
Update tests diagnostics and expected generated ASTs
For backwards compatibility, continue to make `yield from expr`
have an ArrayElement as a child node.
To maintain the invariant that all Nodes must have at least one child,
make $yieldExpression->arrayElement be null when parsing `yield;`
Aside: `yield &$a;` is (and should be)
parsed as the binary operator `(yield) & ($a)`.
This is surprising, but makes sense, being the only sane parse tree.
- Add a unit test that `yield & &$a;` is invalid.
There is no way to parse that.
Verified with the PHP module nikic/php-ast
```php
var_export(ast_dump(
ast\parse_code('<?php function test() { yield & $x; }', 50)
));
```
Previously, the fallback case when something beginning
with the token `$` wasn't a simple variable
would be to assume it would be a complex variable
such as `$$x`
Check that the first token would be valid before recursing.
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.
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.
Noticed test failures for pgsql.phpunit.xml in the drupal project's test
files. (contains the substring ".php")
Also, do the matching on the path name, not on the object to string
conversion.
Rob Lourens
Tyson Andre
Gabriel Caruso
Maarten Staa
Stephan Unverwerth
Tyson Andre
Sara Itani