Add compatibility tests for implicit (un)tupling in patterns.

[varungandhi-apple]

Resolves SR-11212. See the issue description on JIRA for an explanation behind the test cases.

[varungandhi-apple]

@swift-ci please smoke test

[jrose-apple]

Do we already have test cases for the other two forms?

Can you add test cases for the generic one you've been working on, even if they don't work yet?

[varungandhi-apple]

I don't understand which test cases you're referring to in "other two forms" and "generic one"? The table has 4 entries for code which shouldn't compile but still do (on master) -- I've added one function for each such entry. The SR-11160 fix fails two of those tests.

[jrose-apple]

You're right: there should be 12 functions here: all four forms on all three kinds of enum (Untupled, Tupled, and Generic).

[varungandhi-apple]

@swift-ci please smoke test

[jrose-apple]

So, hang on, if these all already work, what's different about SR-11160?

[varungandhi-apple]

Good point! Case 1

switch Optional<(Int, Int)>((5, 6)) { 
case .some(let b): print(b) 
case .none:        print(-1)
}

compiles fine but the supposedly equivalent code Case 2

switch Optional<(Int, Int)>((5, 6)) { 
case let b?: print(b) 
case .none:  print(-1)
}

does not.

The reason this is happening is because the pattern decomposition is incorrect (this is the 3-line fix around conArgSpace in the SR-11160 PR):

_: Optional<(Int, Int)> --> DISJOIN(.none | .some(_: Int, _: Int)) // wrong on master

On master, there is another bug (which I just found out during this investigation), where projecting .some(let b) gives .some(_: Int, _: Int). I will fix this in the SR-11160 PR.

In Case 1, the two bugs cancel out as the overall operation becomes

_: Optional<(Int, Int)> - DISJOIN(.none | .some(_: Int, _: Int))

In Case 2, the pattern that gets formed for let b? is the correct one (because the desugaring does the right thing) so you end up subtracting DISJOIN(.none | .some(let b: (_: Int, _: Int))).

When we try to subtract that from _: Optional<(Int, Int)> we get an error.

[jrose-apple]

Oh wow, so SR-11160 really is specific to the Optional sugar syntax, even if accidentally. Okay, thanks for the explanation, and this looks good to merge!

[jrose-apple]

No wonder we didn't catch it earlier.

[varungandhi-apple]

I think the SR-11160 PR is actually introducing another error because it is allowing illegal subtractions instead of fixing the wrong pattern projection. Investigating that right now.

[okla]

Hello! I have following warning in Xcode 11.4b1 and not sure what does it mean.

$0 is of type Result<(username: String, sessionKey: String), Error>

What exactly should I fix in this code?

[varungandhi-apple]

@okla you can fix it by writing

.success((username, sessionKey))

Sorry for the trouble. We have PR #28076 up for improving the diagnostic but we haven't merged that yet.

[okla]

Now I understand, thanks!