[SR-2887] SILGen incorrect TupleShuffleExpr lowering

[swift-ci]

Previous ID	SR-2887
Radar	None
Original Reporter	TadeasKriz (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Environment

macOS 10.12
Xcode 8.0 (8A218a)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, CompilerCrash, TypeChecker
Assignee	@slavapestov
Priority	Medium

md5: b472bb38b280b09607f3954284081b38

is duplicated by:

• SR-3323 Compiler segmentation fault 11 when insert in array of tuples
• SR-3098 Assertion failed: (!SpecialDests && "shuffle nested within varargs expansion?")

Issue Description:

The following Swift 3.0 ends with Segmentation fault 11.

let data = (a: "", b: 0)
func f(a: String, b: Int) { }
func run<T>(data: T, f: (T) -> ()) { }
run(data: data, f: f)

The problem seems to be in the names of parameters in the `data` tuple. If removed and the tuple is just {code:none}("", 0)

[belkadan]

   Assertion failed: (!destType || destType.getObjectType() == SGF.SGM.Types.getLoweredType(origFormalType, substFormalType).getObjectType()), function materialize, file /Volumes/Data/swift-public/swift/lib/SILGen/ArgumentSource.cpp, line 133.

Yeah, this isn't intended to be legal code any more ((T) -> () can't represent a two-argument function) but there's still more work to do on SE-0110, and of course the compiler shouldn't crash.

[belkadan]

I'm blaming the type checker even though the assertion's in SILGen because by the time we get to SILGen the types should line up.

[belkadan]

(and because the compiler should diagnose this, really)

[swift-ci]

Comment by Tadeas Kriz (JIRA)

@belkadan Thanks for the rename, I wasn't sure how to label it other than the SegFault 11.

Also, you say that it's not legal anymore, but why does changing the

[belkadan]

The compiler is still using tuples to represent function arguments internally, so some cases squeak through. It's not supposed to work either, though. If you want to pass a tuple to a function, the function should take a single argument with tuple type.

[swift-ci]

Comment by Tadeas Kriz (JIRA)

That's a shame. Thanks for the info.

[slavapestov]

'master' has a correct implementation of SE-110, except the diagnostics are still crap. You can see your code fails to typecheck:

Slavas-MBP:swift slava$ ../build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc -Xfrontend -swift-version -Xfrontend 4 tuple.swift 
tuple.swift:4:20: error: cannot convert value of type '(String, Int) -> ()' to expected argument type '(_) -> ()'
run(data: data, f: f)
                   ^

Here is the fixed version:

let data = (a: "", b: 0)
func f(_: (String, Int)) { } // changed 'f' to take a single argument of tuple type instead of two arguments
func run<T>(data: T, f: (T) -> ()) { }
run(data: data, f: f)

However, when we fix this, the SILGen error persists:

Slavas-MBP:swift slava$ ../build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc -Xfrontend -swift-version -Xfrontend 4 tuple.swift 
Assertion failed: (!destType || destType.getObjectType() == SGF.SGM.Types.getLoweredType(origFormalType, substFormalType).getObjectType()), function materialize, file /Users/slava/new/swift/lib/SILGen/ArgumentSource.cpp, line 135.
0  swift                    0x00000001048a5706 SignalHandler(int) + 454
1  libsystem_platform.dylib 0x00007fffb6ad4bba _sigtramp + 26
Stack dump:
0.  Program arguments: /Users/slava/new/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift -frontend -c -primary-file tuple.swift -target x86_64-apple-macosx10.9 -enable-objc-interop -swift-version 4 -color-diagnostics -module-name tuple -o /var/folders/yz/gdc8dvln4x7_m998f3k0ymnw0000gn/T/tuple-41d5f0.o 

So there's a legitimate bug here. I'll take a look.

[slavapestov]

Hey @jckarter, I think we could solve this if SIL type lowering lowered away tuple labels. What do you think?

[slavapestov]

So I think these conversions are legal, and in fact I think they're part of SE-0111. We want a way to add and remove tuple labels. The problem is that SILGen didn't handle this correctly when the tuple conversion appeared in argument position, because of an "different interpretation" implementation of TupleShuffleExpr in ArgEmitter.

[slavapestov]

#6543