Skip to content

Extensions Across Libraries Exposed via @_exported imports with Extension Block Symbols Enabled Produces Invalid Archive #422

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

Closed
2 tasks done
theMomax opened this issue Nov 13, 2022 · 1 comment · Fixed by swiftlang/swift#62409
Labels
bug Something isn't working

Comments

@theMomax
Copy link
Contributor

Description

Note This issue was first discussed here.

Having Lib1 depending on Lib2, and a third target Main reexporting Lib1 and Lib2, and in Lib1 having the extensions defined to the types declared in Lib2, the variables defined in these extensions, are shown on the root level of the doc archive.

E.g. this code produces a top level symbol func foo() in the documentation archive.

// Lib1
public struct Lib1Struct { }

// Lib2
import Lib1

public extension Lib1Struct {
    func foo() { }
}

// Main
@_exported import Lib1
@_exported import Lib2

Checklist

  • If possible, I've reproduced the issue using the main branch of this package.
  • This issue hasn't been addressed in an existing GitHub issue.

Expected Behavior

The expected behavior depends on the discussion around #331. If we decide to implement #331, and do not emit symbols from @_exported imports entirely, we of course would expect the extensions across the re-exported libraries to disappear as well.

If we reject #331 in favor of the current behavior, the expected behavior would be for the symbols resulting from these cross-re-export extensions to be presented as part of the re-exporting target (Main in the example`). These extensions would not be considered extensions to external types, as the types, as well as the extensions, are all re-exported by the same target. That is, there would be no Extended Module sections under which the extension-based symbols are listed. The expected structure of the archive would be as follows:

- Main:
    - Lib1Struct:
        - foo()

Actual behavior

Currently, the structure generated for the example above is as follows:

- Main:
    - Lib1Struct
- foo()

Steps To Reproduce

  1. Make sure you have a setup ready that can produce extension block symbols, e.g. a recent nightly toolchain.
  2. Build the symbol graph files with -emit-extension-block-symbols: swift build --target Main -Xswiftc -emit-symbol-graph -Xswiftc -emit-symbol-graph-dir -Xswiftc .build/symbol-graphs -Xswiftc -omit-extension-block-symbols -Xswiftc -emit-extension-block-symbols
  3. Preview the documentation as usual with docc. Make sure you use an up to date version (main branch).

Swift-DocC Version Information

b9d9ada

Swift Compiler Version Information

Swift version 5.8-dev (LLVM c10fcd3e640b373, Swift 11d9927b51f90d4)
Target: arm64-apple-macosx12.0
@theMomax theMomax added the bug Something isn't working label Nov 13, 2022
theMomax added a commit to theMomax/swift that referenced this issue Dec 5, 2022
do not emit extension block symbols for extensions to external types when the extended type is re-exported by the extending module
QuietMisdreavus pushed a commit to swiftlang/swift that referenced this issue Dec 6, 2022
do not emit extension block symbols for extensions to external types when the extended type is re-exported by the extending module
@QuietMisdreavus
Copy link
Contributor

Note: Because this fix was merged into the compiler's main branch, the fix will be available in the next nightly trunk toolchain, or in the coming 5.8 release (since it was merged before the release branch was split off).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants