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-1076] SILGen crash on overloading functions which take varargs & arrays #43688

Closed
swift-ci opened this issue Mar 27, 2016 · 7 comments
Closed

[SR-1076] SILGen crash on overloading functions which take varargs & arrays #43688

swift-ci opened this issue Mar 27, 2016 · 7 comments
Assignees
@eeckstein
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 SILGen Area → compiler: The SIL generation stage

Comments

@swift-ci
Copy link
Collaborator

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

Swift 2.2 targeting OS X.
Swift main branch in lldb.

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

md5: 86194e98d6c2c806a7809cd01b8f49dd

is duplicated by:

  • SR-1795 SILGen crash on overloading functions which take tuple & individual args
  • SR-1885 Compiler segfault because of overloading & a tuple
  • SR-2231 Overloading array with variadic parameters assertion failure
  • SR-4058 Compiler crashes if overloaded method signature contains varargs followed by a second parameter
  • SR-4141 Segmentation Fault when compiling two functions with default parameters
  • SR-5798 Segfault when building
  • SR-1623 Crash on overload differing in variadic argument

Issue Description:

An overloaded function where one instance takes an array and the other varargs will crash in SILGen.

class Foo {
    func a(arr: Int..., n: String) { }
    func a(arr: [Int], n: String) { }
}

The stack trace from the REPL:

* thread #​1: tid = 0xb9705d, 0x00007fff8ab47f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #​0: 0x00007fff8ab47f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #​1: 0x00007fff885c54ec libsystem_pthread.dylib`pthread_kill + 90
    frame #​2: 0x00000001059da51b swift`::raise(sig=6) + 27 at Signals.inc:421
    frame #​3: 0x00000001059da5d2 swift`::abort() + 18 at Signals.inc:438
    frame #​4: 0x00000001059da5b1 swift`::__assert_rtn(func="preEmitFunction", file="/Users/JoeWillsher/Developer/SWIFT/swift/lib/SILGen/SILGen.cpp", line=484, expr="F->empty() && \"already emitted function?!\"") + 129 at Signals.inc:434
    frame #&#8203;5: 0x00000001005b53e7 swift`void swift::Lowering::SILGenModule::preEmitFunction<swift::FuncDecl>(this=0x00007fff5fbf5a70, constant=SILDeclRef @ 0x00007fff5fbf4b40, astNode=0x000000010e123af0, F=0x0000000113000338, Loc=SILLocation @ 0x00007fff5fbf4b60) + 215 at SILGen.cpp:484
    frame #&#8203;6: 0x00000001005a67fc swift`swift::Lowering::SILGenModule::emitFunction(this=0x00007fff5fbf53a0, f=0x0000000113000338)::$_1::operator()(swift::SILFunction*) const + 204 at SILGen.cpp:573
    frame #&#8203;7: 0x000000010059f695 swift`void emitOrDelayFunction<swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*)::$_1>(SGM=0x00007fff5fbf5a70, constant=SILDeclRef @ 0x00007fff5fbf5288, emitter=0x00007fff5fbf53a0)::$_1&&) + 853 at SILGen.cpp:472
    frame #&#8203;8: 0x000000010059e8b5 swift`swift::Lowering::SILGenModule::emitFunction(this=0x00007fff5fbf5a70, fd=0x000000010e123af0) + 245 at SILGen.cpp:572
    frame #&#8203;9: 0x000000010071dcb9 swift`SILGenExtension::visitFuncDecl(this=0x00007fff5fbf55c8, fd=0x000000010e123af0) + 73 at SILGenType.cpp:465
    frame #&#8203;10: 0x000000010071d6ac swift`swift::ASTVisitor<SILGenExtension, void, void, void, void, void, void>::visit(this=0x00007fff5fbf55c8, D=0x000000010e123af0) + 620 at DeclNodes.def:127
    frame #&#8203;11: 0x000000010071cde5 swift`SILGenExtension::emitExtension(this=0x00007fff5fbf55c8, e=0x000000010e1237b0) + 181 at SILGenType.cpp:437
    frame #&#8203;12: 0x000000010071a72d swift`swift::Lowering::SILGenModule::visitExtensionDecl(this=0x00007fff5fbf5a70, ed=0x000000010e1237b0) + 45 at SILGenType.cpp:512
    frame #&#8203;13: 0x00000001005b6bc4 swift`swift::ASTVisitor<swift::Lowering::SILGenModule, void, void, void, void, void, void>::visit(this=0x00007fff5fbf5a70, D=0x000000010e1237b0) + 116 at DeclNodes.def:90
    frame #&#8203;14: 0x00000001005a439c swift`swift::Lowering::SILGenModule::emitSourceFile(this=0x00007fff5fbf5a70, sf=0x000000010e0b0c00, startElem=1) + 220 at SILGen.cpp:1285
    frame #&#8203;15: 0x00000001005a47bb swift`swift::SILModule::constructSIL(mod=0x000000010e011530, options=0x00007fff5fbfd1b0, SF=0x000000010e0b0c00, startElem=Optional<unsigned int> @ 0x00007fff5fbf5de0, makeModuleFragile=false, isWholeModule=false) + 907 at SILGen.cpp:1314
    frame #&#8203;16: 0x00000001005a5107 swift`swift::performSILGeneration(sf=0x000000010e0b0c00, options=0x00007fff5fbfd1b0, startElem=Optional<unsigned int> @ 0x00007fff5fbf6060, makeModuleFragile=false) + 135 at SILGen.cpp:1378
    frame #&#8203;17: 0x0000000100b0d69d swift`REPLEnvironment::executeSwiftSource(this=0x00007fff5fbf7cb0, Line=(Data = "extension Foo { func a(arr: [Int], n: String) { } }\n", Length = 52), CmdLine=size=9) + 1149 at REPL.cpp:830
    frame #&#8203;18: 0x0000000100b067c8 swift`REPLEnvironment::handleREPLInput(this=0x00007fff5fbf7cb0, inputKind=SourceCode, Line=(Data = "extension Foo { func a(arr: [Int], n: String) { } }\n", Length = 52))::REPLInputKind, llvm::StringRef) + 9432 at REPL.cpp:1151
    frame #&#8203;19: 0x0000000100b03c0f swift`swift::runREPL(CI=0x00007fff5fbfcd48, CmdLine=size=9, ParseStdlib=false) + 303 at REPL.cpp:1176
    frame #&#8203;20: 0x00000001000271e8 swift`performCompile(Instance=0x00007fff5fbfcd48, Invocation=0x00007fff5fbfc6b0, Args=ArrayRef<const char *> @ 0x00007fff5fbf9160, ReturnValue=0x00007fff5fbfaf64) + 4008 at frontend_main.cpp:678
    frame #&#8203;21: 0x0000000100025994 swift`frontend_main(Args=ArrayRef<const char *> @ 0x00007fff5fbfb248, Argv0="/Users/JoeWillsher/Developer/SWIFT/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift", MainAddr=0x000000010000cb70) + 12676 at frontend_main.cpp:1126
    frame #&#8203;22: 0x000000010000dc37 swift`main(argc_=11, argv_=0x00007fff5fbff9c8) + 4231 at driver.cpp:158
    frame #&#8203;23: 0x00007fff9657a5ad libdyld.dylib`start + 1
    frame #&#8203;24: 0x00007fff9657a5ad libdyld.dylib`start + 1

This compiles if there is no param after the vararg/array, or if the overloaded functions are free functions.
@belkadan
Copy link
Contributor

Huh. I guess "has varargs" needs to go into the mangling. :-/ @jckarter?

@jckarter
Copy link
Member

Yeah, this is a known bug. Let me see if I can find the radar.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 8, 2016

Comment by Josef Willsher (JIRA)

It looks like 'has varargs' is only going into the mangling when its the last parameter (possibly a leftover bug from when this was the only legal position?).

In the crashing case, (when compiled separately) both methods are mangled to

@jckarter
Copy link
Member

Yeah, originally variadics were a generalized tuple feature rather than a feature specific to function arguments, and a tuple could only have a variadic element as its last element. The mangling reflects this old design by encoding the function arguments as either a tuple T or variadic tuple t. There's a deeper redesign of the function type and declaration mangling that really needs to happen, to better match the reality of modern Swift, where argument labels are part of the declaration name and should be mangled as part of the name, and functions have multiple independent arguments instead of one argument that may be a tuple.

@ddunbar
Copy link
Member

ddunbar commented May 26, 2016

Would it be possible to diagnose this and give an error on it, until correctly supported?

@jckarter
Copy link
Member

My hunch is that that would be more work than fixing the mangling.

@eeckstein
Copy link
Member

fixed in 327017a

@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

@eeckstein eeckstein

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 SILGen Area → compiler: The SIL generation stage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@ddunbar @jckarter @belkadan @eeckstein @swift-ci @AnthonyLatsis