[llvm-bugs] [Bug 25083] New: Feature request: duplicate symbol warning during linker phase

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=25083

            Bug ID: 25083
           Summary: Feature request: duplicate symbol warning during
                    linker phase
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Linker
          Assignee: unassignedbugs at nondot.org
          Reporter: jverkoey at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Swift encourages the creation of non-namespace-prefixed classes such as Manager
or View. This can lead to unexpected behavior when using multiple Swift
frameworks in an Objective-C target if a symbol exists in multiple frameworks.

For example, say we had the following setup:

// Within Framework1.framework
@objc public class SomeManager: NSObject {
  public func doThing() {
    NSLog(@"SomeManager - Swift - Framework1");
  }
}

// Within Framework2.framework
@objc public class SomeManager: NSObject {
  public func doThing() {
    NSLog(@"SomeManager - Swift - Framework2");
  }
}

And in an Objective-C target we had the following code:

SomeManager *instance = [SomeManager new];  
[instance doThing];

It is undefined whether Framework1 or Framework2's SomeManager will be
instantiated. In fact, on successive builds the instantiated SomeManager may
change. One can imagine this resulting in frustrating debug sessions if the app
developer isn't aware that there are duplicate symbols between the two
frameworks.

This problem already exists in Objective-C, but namespace-prefixing Objective-C
classes is already an accepted practice. Swift rightfully does not encourage
using namespace prefixes, so the problem above is exacerbated. It is possible
to change the symbol of a Swift class for Objective-C builds using @objc(), so
at the very least well-informed Swift engineers will be able to minimize
damage.

All that being said, a warning flag that identified duplicate symbols would be
wonderfully helpful in diagnosing this problem early on.

Alternatively, a way to safely create classes using Framework.ClassName in
Objective-C would be wonderful. Given that it is already possible to
instantiate Swift framework classes this way using NSClassFromString perhaps
this is already in the works.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151007/515604da/attachment.html>