-
Couldn't load subscription status.
- Fork 10.6k
[Parse] Separate compilation condition validation and evaluation #7955
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
Conversation
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test |
|
Do we have tests that Swift 3 mode is unaffected by this change? If so, LGTM. |
81f3210 to
ce6d7f1
Compare
|
@bitjammer Thank you! You can see how this PR breaks Swift3 mode here If these breakage are unacceptable, please let me know. |
|
@swift-ci Please smoke test |
|
You might email swift-dev about it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well-thought-out structure is refreshing to see here. Just one little thing to discuss that isn't pressing at all.
lib/Parse/ParseIfConfig.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only nitpick: I think this could be made to return an Optional<StringRef> - and probably could have a more descriptive name. Right now it matches a member of ValueDecl but does something more specific than ValueDecl's implementation.
ce6d7f1 to
e5a6375
Compare
|
Thanks! @CodaFi |
|
@swift-ci Please smoke test |
|
@rjmccall Please take a look |
|
The Core Team believes this is a bug fix and it is acceptable to break strict source compatibility as long as the practical impact is low. It would be nice to recognize improper precedence in Swift 3 mode and emit an a error with a fixit to add the proper parentheses. Some people on the Core Team felt that you should add a warning about compound names. I don't think this is actually necessary. |
|
Today's core team meeting must've been pretty contentious, it went way over time until 11pm PST :-) |
|
Thanks for discussing this!
Sadly, parentheses can't help 😢 // test.swift
#if FOO || BAR && BAZ
print("OK1")
#endif
#if (FOO || BAR) && BAZ
print("OK2")
#endif
#if FOO || (BAR && BAZ)
print("OK3")
#endifWe can emit a warning without fix-it, but I didn't come up with a good message for that. |
|
May the fix-it change the behavior in Swift3? If so, how about |
Fixes: https://bugs.swift.org/browse/SR-3455 https://bugs.swift.org/browse/SR-3663 https://bugs.swift.org/browse/SR-4032 https://bugs.swift.org/browse/SR-4031 Now, compilation conditions are validated at first, then evaluated. Also, in non-Swift3 mode, '&&' now has higher precedence than '||'. 'A || B && C || D' are evaluated as 'A || (B && C) || D'. Swift3 source breaking changes: * [SR-3663] This used to be accepted and evaluate to 'true' because of short circuit without any validation. #if true || true * 12 = try Anything is OK? print("foo") #endif In this change, remaining expressions are properly validated and diagnosed if it's invalid. * [SR-4031] Compound name references are now diagnosed as errors. e.g. `#if os(foo:bar:)(macOS)` or `#if FLAG(x:y:)` Swift3 compatibility: * [SR-3663] The precedence of '||' and '&&' are still the same and the following code evaluates to 'true'. #if false || true && false print("foo") #endif
and make it to return 'Optional<StringRef>'
e5a6375 to
e58c77f
Compare
|
For @swift-ci Please smoke test |
|
@swift-ci Please smoke test |
compilation condition in Swift3 mode.
e58c77f to
3943b8a
Compare
|
@swift-ci Please smoke test |
|
Implemented warnings for compound names in compilation condition in Swift3 mode. #if FOO(_:)
#endifis accepted with a warning with fix-it to remove parentheses. |
|
@rjmccall Any suggestion for warning messages? |
21dac13 to
bd3b2c6
Compare
|
@swift-ci Please smoke test |
|
@rjmccall Friendly ping :) |
|
@swift-ci please test source compatibility |
1 similar comment
|
@swift-ci please test source compatibility |
|
Once more because I doubt this patch was the cause of the breakage. @swift-ci please test source compatibility |
|
Please anyone can review this? |
|
@DougGregor Can I ask you to approve this, as the code owner of |
|
@bitjammer approved the early version, and @rjmccall said it's okay for Swift 4. @bitjammer, maybe you can look it over once more, and then @rintaro can land this? |
|
Sure thing. |
|
LGTM. |
|
Thank you for this patch, @rintaro, and thanks for your patience in landing it. |
|
Thank you! test again |
Fixes:
https://bugs.swift.org/browse/SR-3455
https://bugs.swift.org/browse/SR-3663
https://bugs.swift.org/browse/SR-4032
https://bugs.swift.org/browse/SR-4031
Now, compilation conditions are validated at first, then evaluated. Also, in non-Swift3 mode,
&&now has higher precedence than||. (i.e.A || B && C || Dare evaluated asA || (B && C) || D.)Swift3 source breaking changes:
[SR-3663] This used to be accepted and evaluate to
truebecause of short circuit without any validation.In this change, remaining expressions are properly validated and diagnosed if it's invalid.
Swift3 compatibility:
[SR-4031] Compound names are diagnosed as warnings in Swift3 mode.
Previously all of these are silently accepted:
Now it's diagnosed with fix-it:
In Swift4 mode, it's rejected.
[SR-3663] The precedence of '||' and '&&' are still the same, and keep the short-circuit rule of Swift3. The following code evaluates to 'true'.