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-5499] Incorrect dynamic dispatch behaviour for nested class overridden across modules when using whole module optimization. #48071

Closed
swift-ci opened this issue Jul 18, 2017 · 7 comments
Closed

[SR-5499] Incorrect dynamic dispatch behaviour for nested class overridden across modules when using whole module optimization. #48071

swift-ci opened this issue Jul 18, 2017 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself optimized only Flag: An issue whose reproduction requires optimized compilation

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-5499
Radar rdar://problem/33391724
Original Reporter derekblr (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Xcode Version 8.3.3 (8E3004b) , iOS 10.3, Swift 3, OSX 10.12.4

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

md5: bd63de410776fc65e4aff1aa55871271

is duplicated by:

  • SR-5497 Incorrect dynamic dispatch behaviour for class overridden across modules when using whole module optimization.

Issue Description:

Suppose in an external module we have these defs:

public struct Woof {
    open class Qux {
        open var name: String? {
            return nil
        }
        public func printName() {
            print(name ?? "no name")
        }
        public init() {}
    }
}

And then in the main module we have this:

class Foo: Woof.Qux {
    override var name: String? {
        return "zorg"
    }    
}

let test = Foo()
test.printName()

Then if run with a release build config, we get "no name".

It should be zorg

We can make it print "zorg" using any of the following changes:

  1. Turn off "whole module optimization" for the external module.

  2. Make Qux a non-nested type by moving it out of Woof.

  3. Put all the code in the same module.
@belkadan
Copy link
Contributor

@swift-ci create

@belkadan
Copy link
Contributor

Possibly fixed in Xcode 9 (I haven't checked).

@iby
Copy link

iby commented Sep 5, 2017

Same issue with initialiser. Suicidal…

@iby
Copy link

iby commented Sep 27, 2017

With Xcode 9 this doesn't work AT ALL! Updated to Swift 4 – no luck either. Changing `SWIFT_OPTIMIZATION_LEVEL` even to none makes no difference, however, with checked `ENABLE_TESTABILITY` it works, at least across unit tests within the same project. Isn't this very critical? ☹️

@iby
Copy link

iby commented Sep 28, 2017

It also works with `Single-File Optimization` and if class wrapped in extension inherits from `NSObject`. Are there any decent ways around this?

@swift-ci
Copy link
Collaborator Author

Comment by Derek Blair (JIRA)

@iby I suppose the least troublesome fix is to remove nesting of the offending class.

@belkadan
Copy link
Contributor

Looks like we did fix the original issue in Xcode 9, but then ran into the issue Ian found where we got the linkage wrong. That one is fixed in swift-4.0-branch even though it didn't make it into Xcode 9 GM, so watch for it in an update.

@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
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself optimized only Flag: An issue whose reproduction requires optimized compilation
Projects
None yet
Milestone
No milestone
Development

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