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.

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-1795] SILGen crash on overloading functions which take tuple & individual args #44404

Closed
swift-ci opened this issue Jun 17, 2016 · 3 comments
Closed

[SR-1795] SILGen crash on overloading functions which take tuple & individual args #44404

swift-ci opened this issue Jun 17, 2016 · 3 comments
Assignees
@eeckstein
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself SILGen Area → compiler: The SIL generation stage

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-1795
Radar rdar://21655241
Original Reporter greglutz (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

This is from swift-DEVELOPMENT-SNAPSHOT-2016-06-06-a-232-gf8a23da. It is a Debug build with assertions enabled (obviously).

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, SILGen
Assignee @eeckstein
Priority Medium

md5: a680aa13b0392d6f7616f89a53d4c776

is blocked by:

  • SR-3179 SourceKitService and lldb-rpc-server crash

duplicates:

  • SR-1076 SILGen crash on overloading functions which take varargs & arrays

is duplicated by:

  • SR-1885 Compiler segfault because of overloading & a tuple
  • SR-3611 Segfault/assertion for simple tuple collection wrapper
  • SR-5416 Compiler crash: generic struct with the tuple parameter of one initializer matching the parameters of another one

Issue Description:

An overloaded function where one instance takes a tuple and the other takes the members of the tuple will crash in SILGen.

func f(_ x:Int, _ y:Int) { }
func f(_ p:(Int, Int)) { }

Here's the stack trace from the swiftc invocation:

Assertion failed: (F->empty() && "already emitted function?!"), function preEmitFunction, file /Users/greg/nsw/swift/lib/SILGen/SILGen.cpp, line 485.
0  swift                    0x0000000109d1795e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1  swift                    0x0000000109d17e89 PrintStackTraceSignalHandler(void*) + 25
2  swift                    0x0000000109d141b9 llvm::sys::RunSignalHandlers() + 425
3  swift                    0x0000000109d18502 SignalHandler(int) + 354
4  libsystem_platform.dylib 0x00007fff90e4652a _sigtramp + 26
5  libsystem_platform.dylib 0x00007fff6f837ac5 _sigtramp + 3734967733
6  swift                    0x0000000109d17eab raise + 27
7  swift                    0x0000000109d17f52 abort + 18
8  swift                    0x0000000109d17f3e __assert_rtn + 126
9  swift                    0x00000001047bec67 void swift::Lowering::SILGenModule::preEmitFunction<swift::FuncDecl>(swift::SILDeclRef, swift::FuncDecl*, swift::SILFunction*, swift::SILLocation) + 215
10 swift                    0x00000001047cf60c swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*)::$_1::operator()(swift::SILFunction*) const + 204
11 swift                    0x00000001047b9e15 void emitOrDelayFunction<swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*)::$_1>(swift::Lowering::SILGenModule&, swift::SILDeclRef, swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*)::$_1&&) + 853
12 swift                    0x00000001047b8a95 swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*) + 245
13 swift                    0x00000001047b898d swift::Lowering::SILGenModule::visitFuncDecl(swift::FuncDecl*) + 61
14 swift                    0x00000001047c162c swift::ASTVisitor<swift::Lowering::SILGenModule, void, void, void, void, void, void>::visit(swift::Decl*) + 620
15 swift                    0x00000001047c11dc swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, unsigned int) + 220
16 swift                    0x00000001047c1aeb swift::SILModule::constructSIL(swift::ModuleDecl*, swift::SILOptions&, swift::FileUnit*, llvm::Optional<unsigned int>, bool, bool) + 907
17 swift                    0x00000001047c2997 swift::performSILGeneration(swift::FileUnit&, swift::SILOptions&, llvm::Optional<unsigned int>, bool) + 135
18 swift                    0x00000001044a5aa1 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*) + 6865
19 swift                    0x00000001044a351c swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 12764
20 swift                    0x00000001043fa5fc main + 4236
21 libdyld.dylib            0x00007fff8e10c5ad start + 1
Stack dump:
0.  Program arguments: /Users/greg/nsw/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift -frontend -emit-silgen -primary-file t1.swift -target x86_64-apple-macosx10.9 -enable-objc-interop -Onone -parse-as-library -module-name t1 -o t1.sil 
1.  While emitting SIL for 'f' at t1.swift:2:1
sil: line 9: 18705: Illegal instruction

Both function names are mangling to TF3t1v1fFTSiSi_T

It appears that treating a function's input as, and mangling its name as, simply a tuple is problematic.
@swift-ci
Copy link
Collaborator Author

Comment by Greg Lutz (JIRA)

I don't believe this bug is a duplicate of SR-1076. They certainly appear similar (in fact, I copied the structure of SR-1076 when composing my bug report), but this bug (SR-1795) is specific to the way Swift handles a function definition with exactly one parameter. The parameter list to a function is treated as a tuple. SilGEN's canonicalization process leaves lists of 0, 2, or more parameters as tuples, but the TupleType representing a single-parameter list is transformed, first, to a ParenType (see first statement in

TupleType::get(ArrayRef<TupleTypeElt>Fields, const ASTContext &C)

in (swift/lib/AST/)ASTContext.cpp), and then later to the ParenType's underlying type (by "desugaring"). So if the single parameter is itself a tuple, the result is a canonical type duplicating that of a function whose arguments are just the members of the tuple. The parser thinks these functions are different, but SilGEN thinks they have the same type.

I don't know quite what's going on in SR-1076, but it's not this.

@belkadan
Copy link
Contributor

I think it's just something we'd fix at the same time. It's the same basic issue of "these things are getting the same mangling when they shouldn't".

@eeckstein
Copy link
Member

fixed in 11f66f8

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@eeckstein eeckstein

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself SILGen Area → compiler: The SIL generation stage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@belkadan @eeckstein @swift-ci