-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Make escaping on ternary expressions more fine-grained #2934
Conversation
a71800c
to
b86c6de
Compare
@stof @nicolas-grekas Could you review this PR please? It's an important one as it involves escaping and I don't want to introduce a security issue. |
2290cc4
to
7b85aa5
Compare
ed34d1a
to
00a6c2b
Compare
00a6c2b
to
7e6e0a6
Compare
7e6e0a6
to
71c36dc
Compare
The existing auto-escaping rule (requiring both sides to be safe for the ternary to be safe) still applies when the ternary is nested in a more complex expressions ( |
@stof that's correct. |
71c36dc
to
205b2c9
Compare
Then the doc needs to make this more clear IMO. The note you added may make people think this would not be the case anymore. |
We have an optimization in NullCoalesceExpression to use Should we unwrap things and wrap then in an InlinePrintNode all the time, or only when the safety rules would be different for both branches ? If rules are the same in both branches, applying the escaping as done today does not hurt, but let the ConditionalExpression optimize itself when possible. |
205b2c9
to
ac8f367
Compare
@stof we now only unwrap when the safety is not the same on the two branches. |
ac8f367
to
906672e
Compare
906672e
to
dfa9411
Compare
closes #2146
closes #449
closes #539
closes #1174
closes #1320
closes #1739
closes #1333