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

[SR-1854] compiler crash for closure with tuple #44463

Closed
swift-ci opened this issue Jun 21, 2016 · 5 comments
Closed

[SR-1854] compiler crash for closure with tuple #44463

swift-ci opened this issue Jun 21, 2016 · 5 comments
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

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-1854
Radar None
Original Reporter VladimirS (JIRA User)
Type Bug
Status Closed
Resolution Cannot Reproduce
Environment

IBM Swift Sandbox
Swift Ver. 3.0 (Jun 6, 2016)
Target: x86_64-ubuntu-linux-gnu

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, CompilerCrash
Assignee None
Priority Medium

md5: ceeff5fc884b27df509c065f88320a3b

relates to:

Issue Description:

This code crashes the compiler, as I understand from the output:

let ft2 : (Int,Int) -> Void = { x in print(x) }

ft2(1, 2)
Unhandled conversion from exploded tuple
UNREACHABLE executed at /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/swift/lib/SILGen/SILGenPoly.cpp:879!
0  swift           0x00000000032ecf28 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  swift           0x00000000032eb726 llvm::sys::RunSignalHandlers() + 54
2  swift           0x00000000032eda56
3  libpthread.so.0 0x00007fb389be7d10
4  libc.so.6       0x00007fb38852f1c7 gsignal + 55
5  libc.so.6       0x00007fb388530e2a abort + 362
6  swift           0x000000000329b92d llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 461
7  swift           0x00000000009b6aad
8  swift           0x00000000009bf6f5
9  swift           0x00000000009b2b63
10 swift           0x00000000009b245c
11 swift           0x000000000098b0ff
12 swift           0x000000000097fd1d
13 swift           0x000000000096feb9
14 swift           0x000000000096ff9d
15 swift           0x00000000009349fe
16 swift           0x00000000009352fb
17 swift           0x0000000000936002 swift::SILModule::constructSIL(swift::ModuleDecl*, swift::SILOptions&, swift::FileUnit*, llvm::Optional<unsigned int>, bool, bool) + 482
18 swift           0x0000000000936596 swift::performSILGeneration(swift::FileUnit&, swift::SILOptions&, llvm::Optional<unsigned int>, bool) + 118
19 swift           0x00000000007d973f
20 swift           0x00000000007d578e swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2830
21 swift           0x00000000007a277b main + 2603
22 libc.so.6       0x00007fb38851aac0 __libc_start_main + 240
23 swift           0x00000000007a02f9 _start + 41
Stack dump:
0.  Program arguments: /usr/bin/swift -frontend -c -primary-file /swift-execution/Sources/main.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -I /swift-execution/.build/debug -enable-testing -g -module-cache-path /swift-execution/.build/debug/ModuleCache -D SWIFT_PACKAGE -emit-module-doc-path /swift-execution/.build/debug/TempCode.build/main~partial.swiftdoc -Onone -module-name TempCode -emit-module-path /swift-execution/.build/debug/TempCode.build/main~partial.swiftmodule -emit-dependencies-path /swift-execution/.build/debug/TempCode.build/main.d -emit-reference-dependencies-path /swift-execution/.build/debug/TempCode.build/main.swiftdeps -num-threads 8 -o /swift-execution/.build/debug/TempCode.build/main.swift.o 
1.  While emitting reabstraction thunk in SIL function @_TTRXFo_iP___XFo_dSidSi__<unknown>:0: error: unable to execute command: Aborted
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)
@jepers
Copy link

jepers commented Jun 21, 2016

Some more tuple-trouble related to this:

let c0 : (Int, Int) -> Void = { (x) -> Void in print(x.0, x.1) }
let c1 : (Int, Int) -> Void = { (x: (Int, Int)) -> Void in print(x.0, x.1) }
let c2                      = { (x: (Int, Int)) -> Void in print(x.0, x.1) }
c0(1, 2)
c1(1, 2)
c2((1, 2)) // <-- NOTE: Only compiles with extra parens.
// Also note that c1 and c2 are identical except that c1 has its type given
// explicitly while c2 lets the type checker infer it.
// And look at this:
print(c1.dynamicType) // Prints ((Int, Int)) -> ()
print(c2.dynamicType) // Prints ((Int, Int)) -> ()
// And this:
print(c1.dynamicType == c2.dynamicType) // Prints true

@jepers
Copy link

jepers commented Jun 22, 2016

Or perhaps more clearly formulated:

typealias BinaryIntOp_v1 = (Int, Int) -> Int
typealias BinaryIntOp_v2 = ((Int, Int)) -> Int

print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int
print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int

let areRepresentingTheSameType = BinaryIntOp_v1.self == BinaryIntOp_v2.self // (alt-click the "==" and read doc.)
print(areRepresentingTheSameType) // Prints true

let add_v1: BinaryIntOp_v1 = (+)
let add_v2: BinaryIntOp_v2 = (+) // Or both could have been eg: { return $0 + $1 }

let ra = add_v1(1, 2)
let rb = add_v2((1, 2)) // NOTE: Needs these extra parens (otherwise error: "Extra argument in call")

let rc = (add_v1 as BinaryIntOp_v2)((1, 2)) // NOTE: I am type casting these to an identical type ...
let rd = (add_v2 as BinaryIntOp_v1)(1, 2)   // ... in order to swap which one of them need extra parens ...

@swift-ci
Copy link
Collaborator Author

Comment by Vladimir (JIRA)

Any news on this ?

@ahoppen
Copy link
Contributor

ahoppen commented Jul 13, 2016

Can't reproduce on current master. Seems to have been fixed in the meantime.

@jepers
Copy link

jepers commented Jul 29, 2016

I've created a separate issue for the stuff demonstrated by my code examples above, here: https://bugs.swift.org/browse/SR-2216

@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
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
Projects
None yet
Development

No branches or pull requests

4 participants