unused_import and dynamic linking
Nobody has claimed this yet.
- Dominant language
- Swift
- Stars
- 19.7k
- Forks
- 2.3k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 11
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the unused_import rule and its existing tests, then review how it decides which imports can be removed. Use the protocol-inheritance and default-parameter examples as cases to investigate. Done would require an agreed behavior for dynamic-linking dependencies and tests showing that required imports are preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100