Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Using short echo syntax with commas: <?=$a, $b;?> #220

Closed
felixfbecker opened this issue Feb 9, 2018 · 5 comments
Closed

Using short echo syntax with commas: <?=$a, $b;?> #220

felixfbecker opened this issue Feb 9, 2018 · 5 comments

Comments

@felixfbecker
Copy link

From @bibainet on February 9, 2018 15:6

PHP IntelliSense reports error/problem on <?=$a, $b;?> constructs (short echo syntax with commas):

[php] ';' expected.
[php] Unexpected ','

Screenshot:

vscode_php_echo_comma_bug

  • VSCode: 1.20 and lower.
  • PHP IntelliSense: 2.2.7 and lower.
  • Windows 7/10.

Copied from original issue: felixfbecker/php-language-server#596
@felixfbecker
Copy link
Author

Do you have short tags enabled?

@felixfbecker
Copy link
Author

From @bibainet on February 9, 2018 19:26

Yes. The 'php.executablePath' (and also 'php.validate.executablePath') option points to a working PHP 7 executable, and there is 'short_open_tag = On' option in 'php.ini' in this directory.
Short echo tags () are always enabled in PHP 5.4+ regardless of this option.

@felixfbecker
Copy link
Author

Just to be sure (because this issue has come up quite a few times and there can be multiple php.ini at play), could you run php -i and check? Where php is the php from php.executablePath

@felixfbecker
Copy link
Author

From @bibainet on February 9, 2018 19:36

The output of php -i:

PHP Version => 7.2.0
Loaded Configuration File => D:\Work\PHP7\php.ini
Scan this dir for additional .ini files => (none)
Additional .ini files parsed => (none)
...
short_open_tag => On => On

@felixfbecker felixfbecker mentioned this issue Feb 9, 2018
Closed
@TysonAndre
Copy link
Contributor

TysonAndre commented Feb 9, 2018 •
edited
Loading

Related to #185 (tolerant-php-parser uses token_get_all() directly, which is affected by the short_open_tag setting.

EDIT: Never mind, <?= is always enabled.

TysonAndre added a commit to TysonAndre/tolerant-php-parser that referenced this issue May 12, 2018
@TysonAndre
Work on properly parsing the expression lists passed to <?=
e15c880 
Before, tolerant-php-parser parsed the tokens after `<?=` and `<?php`
the same way.

Fixes microsoft#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 `EchoExpression` for simplicity. The resulting expression
will have no `echoKeyword` because `<?=` was part of the preceding
`InlineHTML` Node.

- In the majority of cases,
  the EchoExpression will be moved into the outer statement list.
TysonAndre added a commit to TysonAndre/tolerant-php-parser that referenced this issue May 13, 2018
@TysonAndre
Work on properly parsing the expression lists passed to <?=
d0ab7a4 
Before, tolerant-php-parser parsed the tokens after `<?=` and `<?php`
the same way.

Fixes microsoft#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 `EchoExpression` for simplicity. The resulting expression
will have no `echoKeyword` because `<?=` was part of the preceding
`InlineHTML` Node.

- In the majority of cases,
  the EchoExpression will be moved into the outer statement list.
TysonAndre added a commit to TysonAndre/tolerant-php-parser that referenced this issue Jun 7, 2018
@TysonAndre
Work on properly parsing the expression lists passed to <?=
bafcb4a 
Before, tolerant-php-parser parsed the tokens after `<?=` and `<?php`
the same way.

Fixes microsoft#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 `EchoExpression` for simplicity. The resulting expression
will have no `echoKeyword` because `<?=` was part of the preceding
`InlineHTML` Node.

- In the majority of cases,
  the EchoExpression will be moved into the outer statement list.
TysonAndre added a commit to TysonAndre/tolerant-php-parser that referenced this issue Jun 7, 2018
@TysonAndre
Work on properly parsing the expression lists passed to <?=
e0e22e5 
Before, tolerant-php-parser parsed the tokens after `<?=` and `<?php`
the same way.

Fixes microsoft#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 `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 EchoExpression will be moved into the outer statement list.

Fix parsing "echo" statements - echo is a statement, not an expression

- `echo exprList` can't be used as an expression.

- Contrast with `print expr`, (`PrintIntrinsicExpression`),
  which is correctly treated as an expression.

Update documentation
TysonAndre added a commit to TysonAndre/tolerant-php-parser that referenced this issue Jun 9, 2018
@TysonAndre
Work on properly parsing the expression lists passed to <?=
73606f5 
Before, tolerant-php-parser parsed the tokens after `<?=` and `<?php`
the same way.

Fixes microsoft#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)
roblourens added a commit that referenced this issue Jun 11, 2018
@roblourens
Merge pull request #245 from TysonAndre/fix-short-echo
bce97ae 
Fixes #220 : Properly parse expression lists passed to `<?=`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@TysonAndre @felixfbecker