Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[SR-2887] SILGen incorrect TupleShuffleExpr lowering #45481

Closed
swift-ci opened this issue Oct 7, 2016 · 10 comments
Closed

[SR-2887] SILGen incorrect TupleShuffleExpr lowering #45481

swift-ci opened this issue Oct 7, 2016 · 10 comments
Assignees
@slavapestov
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Oct 7, 2016

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
Copy link
Contributor

belkadan commented Oct 7, 2016 

   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
Copy link
Contributor

belkadan commented Oct 7, 2016

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
Copy link
Contributor

belkadan commented Oct 7, 2016

(and because the compiler should diagnose this, really)

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 7, 2016

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
Copy link
Contributor

belkadan commented Oct 7, 2016

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
Copy link
Collaborator Author

swift-ci commented Oct 7, 2016

Comment by Tadeas Kriz (JIRA)

That's a shame. Thanks for the info.

@slavapestov
Copy link
Member

'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
Copy link
Member

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

@slavapestov
Copy link
Member

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
Copy link
Member

#6543

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slavapestov slavapestov

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@slavapestov @belkadan @swift-ci @AnthonyLatsis