unused_import and dynamic linking
Context: We would like to build with dynamic linking – building each module as a dynamic library (or framework) instead of static library (archive). This is for developer builds, not release.
One issue with dynamic linking are the cases where swiftc can in some cases reference transitive dependency modules, beyond the modules directly imported in source.
A more well known case of this is calling an extension function without importing the module that defines the extension. See SR-11901.
But there are other cases where a transitive dependency exists in the binary, which can cause dynamic linking to fail. We'd like to add these missing imports, to accurately reflect the dependencies needed for linking, but unused_import will currently delete these imports.
Can unused_import be changed to support imports that reflect the dependencies that are needed for dynamic linking?
I would like to contribute to the work needed to accomplish this, and I'm looking for guidance on how to approach this since not everyone will want such functionality.
Here are some examples we've seen:
- Protocol inheritance
- Default parameter values
Here are some brief examples of each of these:
Protocol inheritance
// Module A
public protocol BaseProto {}
// Module B
import A
public protocol SubProto: BaseProto {}
// Module C
import B
public class SomeClass: SubProto {}
In this example, module C depends on A since it will reference the protocol descriptor symbol for BaseProto. Not intuitively, there is effectively a missing import A. Swift doesn't need this dependency spelled out, the linker does.
Default parameter values
// Module A
public func theDefault() -> Thing {}
// Module B
import A
public func someFunc(_ thing: Thing = theDefault()) {}
// Module C
import B
func f() {
someFunc()
}
In this example, module C depends on A since it will reference the default argument symbol for theDefault(). Not intuitively, there is effectively a missing import A. Swift doesn't need this dependency spelled out, the linker does.
This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!
Still relevant
This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!