Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Revise how modules imports are done to better support import public #1539

Merged
merged 2 commits into from
Jan 11, 2024
Merged

Revise how modules imports are done to better support import public #1539

merged 2 commits into from
Jan 11, 2024

Commits on Jan 8, 2024

  1. Add a CompileTest for "multi module" generation. 

    - Add basic infrastructure to have Compile Tests.

- Add a specific MultiModule CompileTest.
  - This ensure that with `import public` is properly handle and the generated
    code compiles even when a needed type is coming from a public import.
  - So the any relevant code changes are more visible, check the the generated
    code so the diffs for an changes related to the test will be easily
    reviewed.
  - The SPM plugin doesn't support multi module generation
    (apple#1450), which is also why the
    code needs to be checked in, otherwise, it might simplify the tests.

Note: The whole concept of CompileTests doesn't have to be a set up as distinct
Swift Packages, but if we put the required targets in the main Package.swift,
all projects using swift-protobuf would end up having the "overhead" of those
test only targets, so I've errored on the side of a distinct package to make
sure there is no impact of these tests on the folks using swift-protobuf.
    @thomasvl
    thomasvl committed Jan 8, 2024
    Configuration menu
    Copy the full SHA
    5c215b2 View commit details
    Browse the repository at this point in the history

  2. Revise how modules imports are done to better support import public 

    Historically Swift didn't have a good way to model `import public` in .proto
files. But by using `@_exported import`, we can get the majority of the way
there. This makes restructuring of proto files less likely to break Swift source
code; meaning Swift is less of a "special case" compared to other languages.

If generating with `public` or `package` visibility, then instead of importing
the whole module of for an `import public`, explicitly re-export the imports of
the types from that file. That will make them usable for the given source file
but will also let the types continue to be used by someone just importing this
module.

This also means a file with no `import public` usages becomes must simpler as it
can just rely on its direct dependencies to provide all the types that could be
used.
    @thomasvl
    thomasvl committed Jan 8, 2024
    Configuration menu
    Copy the full SHA
    b27d019 View commit details
    Browse the repository at this point in the history