<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Feature request: duplicate symbol warning during linker phase"
href="https://llvm.org/bugs/show_bug.cgi?id=25083">25083</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Feature request: duplicate symbol warning during linker phase
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Linker
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jverkoey@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>