Skip to content

[ExpressionLanguage] # character in a string literal #11433

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.

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

Closed
pylebecq opened this issue Jul 21, 2014 · 7 comments
Closed

[ExpressionLanguage] # character in a string literal #11433

pylebecq opened this issue Jul 21, 2014 · 7 comments

Comments

@pylebecq
Copy link
Contributor

Hey there,

It seems # character in string literals breaks the expression parsing but only when using double quotes as a string delimiter.

Some pseudo code to illustrate this:

$language = new ExpressionLanguage();

// throws SyntaxError exception
$language->parse('user.getGroup() in ["#good_customers", "#collaborator"]', array('user')); 

// valid
$language->parse("user.getGroup() in ['#good_customers', '#collaborator']", array('user')); 

Does the # character mean something ? Why is there a difference between single and double quoted strings ?

I did not find anything related to this in the documentation, and I think the answers to these questions have to be documented somewhere.

@sstok
Copy link
Contributor

sstok commented Jul 22, 2014

It seems to have a special meaning.
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ExpressionLanguage/Lexer.php#L72

But I can not see what for.

@pylebecq
Copy link
Contributor Author

I noticed the regex. That's how I figured out I could use single quoted strings as a workaround, but I did not find anything beyond the regex, that's why I'm asking.

@sstok
Copy link
Contributor

sstok commented Jul 22, 2014

It seems this is a leftover from the Twig copying.

The original PR #8913 mentions its based on Twig Expression.
And looking the Twig code the regex is identical.
https://github.com/fabpot/Twig/blob/master/lib/Twig/Lexer.php#L44

Now looking at Twig documentation, the # is used for String Interpolation

And in Twig, String Interpolation is handled separately in the lexing process.

Now for the 100 dollar question, should String Interpolation added to the ExpressionLanguage or should the matching of # as special character be removed? 😋

@fabpot
Copy link
Member

fabpot commented Jul 22, 2014

The expression language does not support string interpolation. So, that's a left over that should be removed to fix this issue. Anyone willing to provide a PR?

@pylebecq
Copy link
Contributor Author

Sure, I will.
Thanks for the heads-up guys.

fabpot added a commit that referenced this issue Jul 23, 2014
…ontaining sharps (pylebecq)

This PR was merged into the 2.4 branch.

Discussion
----------

[ExpressionLanguage] Fixed double quoted string literals containing sharps

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #11433
| License       | MIT
| Doc PR        | n/a

Commits
-------

0c2622e [ExpressionLanguage] Fixed an issue with # characters in double quoted string literals
@fabpot fabpot closed this as completed Jul 23, 2014
@webdevilopers
Copy link

Sorry for commenting on this closed issue. I just wanted to ask if the asterisk has a functionality too?
I accidentally added some line breaks to the Expression using annotation:

   /**
     * @Assert\Expression(
     *     "!(this.type in [
     *          constant('App\\Domain\\Model\\Foo\\Foo::bar'),              
     *          constant('App\\Domain\\Model\\Foo\\Foo::baz')
     *     ] and value == null)"
     * )
     */

Throwing:

Unexpected token "operator" of value "*" around position 23.
in vendor/symfony/symfony/src/Symfony/Component/ExpressionLanguage/Parser.php at line 230

Not sure if this woul happen using YAML too:

@pylebecq
Copy link
Contributor Author

Hello.
I think in your case the asterisk is just the multiplication operator.
So indeed, having an operator right after an open square bracket for example is not expected by the parser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants