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-10032] Crash using a class and protocol constraint on a collection passed to the Set initializer #52435

Open
tjw opened this issue Mar 2, 2019 · 7 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 optimized only Flag: An issue whose reproduction requires optimized compilation

Comments

@tjw
Copy link
Contributor

tjw commented Mar 2, 2019

Previous ID SR-10032
Radar rdar://problem/48566320
Original Reporter @tjw
Type Bug

Attachment: Download

Environment

Xcode 10.1 or Xcode 10.2b3

macOS 10.14.3

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

md5: 13545070b8de89da21dab248cbe72e95

Issue Description:

The following code crashes the compiler when built in Release mode:

@objc public protocol P : NSObjectProtocol {}

private func _makeCopies<C: Collection>(objects: C) where C.Element : NSObject & P {
    _ = Set(objects)
}
public func duplicateSections() {
    let objects = [NSObject & P]()
    _makeCopies(objects: objects)
}

with the backtrace:

1.  While running pass #&#8203;1117 SILFunctionTransform "EarlyInliner" on SILFunction "@$ss10_NativeSetV6resize8capacityySi_tF9CrashTest1P_So8NSObjectCXc_Tg5".
 for <<debugloc at "<compiler-generated>":0:0>>0  swift                    0x000000010504befa PrintStackTraceSignalHandler(void*) + 42
1  swift                    0x000000010504b6dc SignalHandler(int) + 348
2  libsystem_platform.dylib 0x00007fff7d0f1b3d _sigtramp + 29
3  libsystem_platform.dylib 0x00007f851fa9d068 _sigtramp + 2728047944
4  swift                    0x0000000101e3b5be swift::SILInstructionVisitor<swift::SILInlineCloner, void>::visit(swift::SILInstruction*) + 13886
5  swift                    0x0000000101e36ac3 swift::SILInliner::inlineFunction(swift::SILFunction*, swift::FullApplySite, llvm::ArrayRef<swift::SILValue>) + 6003
6  swift                    0x0000000101d2124e (anonymous namespace)::SILPerformanceInlinerPass::run() + 1438
7  swift                    0x0000000101c909bb swift::SILPassManager::execute() + 4587
8  swift                    0x0000000100ebb7b5 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 46789
9  swift                    0x0000000100eacac7 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 6823
10 swift                    0x0000000100e4c90d main + 1261
11 libdyld.dylib            0x00007fff7cf06ed9 start + 1
  • Open the attached project

  • Ensure the build configuration is set to Release

  • Build

  • Crash

@tjw
Copy link
Contributor Author

tjw commented Mar 2, 2019

Inlining the private function into the caller results in an error instead of a crash, `'NSObject & P' cannot be used as a type conforming to protocol 'Hashable' because 'Hashable' has static requirements`

@tjw
Copy link
Contributor Author

tjw commented Mar 2, 2019

In this case, a workaround was to convert the incoming Collection<NSObject & P> to [NSObject] before passing it off to the Set initializer with Set(objects.map { $0 as NSObject}). This avoided the compiler getting confused about how to deal with Hashable for the given type. It seems like it shouldn't have been a problem since both NSObject and P get -hash from NSObjectProtocol.

@belkadan
Copy link
Contributor

belkadan commented Mar 4, 2019

With assertions:

Assertion failed: (optConformance && "existential type didn't self-conform"), function subst, file /Volumes/Data/swift-public/swift/lib/AST/ProtocolConformance.cpp, line 121.
Stack dump:
0.  Program arguments: /Volumes/Data/swift-public/build/ninja/swift-macosx-x86_64/bin/swift -frontend -c -primary-file - -target x86_64-apple-darwin18.5.0 -enable-objc-interop -sdk /Volumes/Data/Applications/Xcode10.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -O -color-diagnostics -module-name main -o /var/folders/_d/dmrgv26d3bs6lkrks9z825_w0000gn/T/--bcbf87.o 
1.  While running pass #&#8203;1174 SILFunctionTransform "GenericSpecializer" on SILFunction "@$s4main11_makeCopies33_1A61A3E7348A44FC8FF8726B26BEB4EDLL7objectsyx_tSlRzSo8NSObjectC7ElementRczAA1PAHRQlFSayAaI_AFXcG_Tg5".
 for '_makeCopies(objects:)' (at <stdin>:5:9)

NSObjectProtocol isn't actually Hashable, because protocols can't conform to other protocols today, but throwing away the `& P` part would have worked. @eeckstein, who handles inlining these days?

@eeckstein
Copy link
Member

@belkadan The crash is already in the GenericSpecializer. Anyway, this looks like a type-system/frontend issue.

@belkadan
Copy link
Contributor

belkadan commented Mar 4, 2019

Ah, good point. SR-10031 shows that this should have been rejected.

@belkadan
Copy link
Contributor

belkadan commented Mar 4, 2019

Er, wait, no, it's an @objc protocol. That means we do accept this, but maybe we don't SILGen it correctly.

@tjw
Copy link
Contributor Author

tjw commented Oct 8, 2019

This is still an issue in Xcode 11.2b1

@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
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 optimized only Flag: An issue whose reproduction requires optimized compilation
Projects
None yet
Development

No branches or pull requests

4 participants