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-10177] Failed to demangle superclass when using Objective-C type as type argument #52579

Open
swift-ci opened this issue Mar 26, 2019 · 6 comments

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Mar 26, 2019

Previous ID SR-10177
Radar None
Original Reporter SvyatoslavScherbina (JIRA User)
Type Bug
Environment
Apple Swift version 5.0 (swiftlang-1001.0.69.5 clang-1001.0.46.3)
Target: x86_64-apple-darwin18.2.0
Additional Detail from JIRA
Votes 2
Component/s
Labels Bug, Runtime
Assignee None
Priority Medium

md5: 82002288449e014fc4cc52035d72b0d1

Issue Description:

1.h

#import <Foundation/Foundation.h>
@interface Foo : NSObject
@end;

1.swift:

class Base<T> {}
class Derived : Base<Foo> {}

Derived()
$ swiftc 1.swift -import-objc-header 1.h

The resulting binary crashes with

failed to demangle superclass of Derived from mangled name 'M???ySo3FooCG'
@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Mar 26, 2019

Comment by Svyatoslav Scherbina (JIRA)

The similar test crashes with segmentation fault if Foo is protocol.

The issue seem to appear only when the corresponding Objective-C class or protocol definition is not found among linked binaries.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Mar 26, 2019

I think it's reasonable for that not to work, but it would be nice™ if it gave a more direct error message. cc @DougGregor

@DougGregor
Copy link
Member

@DougGregor DougGregor commented Mar 26, 2019

I agree with both of Jordan's comments: it's reasonable for this to fail, because the metadata for `Foo` needs to exist in the binary. It would also be wonderful to have a more specific error message when the process of constructing types from a mangled name fails.

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Mar 27, 2019

Comment by Svyatoslav Scherbina (JIRA)

Please consider the following two failing examples:

1.

import Accounts

class Base<T> {}
class Derived : Base<ACAccount> {}

Derived()

Accounts framework is not linked because not considered as used by the compiler. And then Swift runtime fails because it can't find the class from this framework.

2.

import Foundation

class Base<T> {}
class Derived : Base<NSURLDownloadDelegate> {}

Derived()

Foundation framework is linked, but protocols code is generated on demand, and NSURLDownloadDelegate hasn't been requested properly. So it can't be found at runtime and the application crashes with segmentation fault.

Do you still find current behaviour completely reasonable?

@belkadan
Copy link
Contributor

@belkadan belkadan commented Mar 27, 2019

Both of those cases are bugs in the compiler (or linker) in that they don't consider the framework to be used! Can you file a separate bug for that?

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Mar 28, 2019

Comment by Svyatoslav Scherbina (JIRA)

Sure! SR-10217

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

No branches or pull requests

3 participants