Fixing complation condition processing

rintaro · 2017-03-08T07:11:43.000Z

Hi all,

I'm fixing #if condition processing in this PR

github.com/apple/swift

[Parse] Separate compilation condition validation and evaluation

apple:master ← rintaro:parse-ifconfig-validate

opened 05:28PM - 07 Mar 17 UTC

rintaro

+770 -424

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 || 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. ```swift #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. **Swift3 compatibility:** * [SR-4031] Compound names are diagnosed as warnings in Swift3 mode. Previously all of these are silently accepted: ```swift #if BAR(_:) #elseif os(x:)(macOS) #elseif os(Linux(foo:bar:)) #endif ``` Now it's diagnosed with fix-it: ``` warning: ignoring parentheses in compound name, which will be rejected in future version of Swift #if BAR(_:) ^~~~ ``` 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'. ```swift #if false || true && false print("foo") #endif ```

It resolves these issues:

*A) SR-3663 <Issues · apple/swift-issues · GitHub Precedence of '&&' and
'||' and short-circuit rule of them.*

#if false || true && false print("true")#endif

This used to evaluate to 'true'.

*B) SR-4032 <Issues · apple/swift-issues · GitHub Version check with
binary operator.*

#if swift(>=5.0) && FOO
Some Swift 5 code here
#endif

I believe, this block should not be parsed.

*C) SR-3663 <Issues · apple/swift-issues · GitHub Invalid condition
after short-circuit binary operator.*

#if true || true * This is not <acceptable>!
#endif

This used to be accepted.

*D) SR-4031 <Issues · apple/swift-issues · GitHub Compound name in the
condition*

#if FOO(_:)
#elseif os(foo:)(macOS)
#elseif os(Linux(foo:bar:))
#endif

This used to be accepted.

In the PR, I keep A) and B) behavior in -swift-version 3 mode.
However, as for C) and D), I don't think it's worth to keep them even in
Swift3 mode, because they are obviously wrong.

What do you think? Do we need accept them in Swift3 mode?

codafi · 2017-03-14T05:28:40.000Z

I think the source breakage here, if any in actual codebases, is minor enough that the patch could go through.

~Robert Widmann

···

On Mar 8, 2017, at 2:11 AM, rintaro ishizaki via swift-dev <swift-dev@swift.org> wrote:

Hi all,

I'm fixing if condition processing in this PR
[Parse] Separate compilation condition validation and evaluation by rintaro · Pull Request #7955 · apple/swift · GitHub

It resolves these issues:

A) SR-3663 <Issues · apple/swift-issues · GitHub Precedence of '&&' and '||' and short-circuit rule of them.

if false || true && false
print("true")
#endif

This used to evaluate to 'true'.

B) SR-4032 <Issues · apple/swift-issues · GitHub Version check with binary operator.

if swift(>=5.0) && FOO
Some Swift 5 code here
#endif

I believe, this block should not be parsed.

C) SR-3663 <Issues · apple/swift-issues · GitHub Invalid condition after short-circuit binary operator.

if true || true * This is not <acceptable>!
#endif

This used to be accepted.

D) SR-4031 <Issues · apple/swift-issues · GitHub Compound name in the condition

if FOO(_:)
#elseif os(foo:)(macOS)
#elseif os(Linux(foo:bar:))
#endif

This used to be accepted.

In the PR, I keep A) and B) behavior in -swift-version 3 mode.
However, as for C) and D), I don't think it's worth to keep them even in Swift3 mode, because they are obviously wrong.

What do you think? Do we need accept them in Swift3 mode?
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev