Skip to content

NFC: Test printing swiftinterfaces containing declarations originally written using typealiases from another module #60179

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

Merged
merged 2 commits into from
Jul 22, 2022

Conversation

tshortli
Copy link
Contributor

This test establishes a baseline for the behavior of swiftinterface emission when public declarations of all kinds reference typealiases from another module. It seems that for many types of declarations, the printer is looking through the typealias definition and printing the original type instead of a fully qualified reference to the typealias. This behavior can cause swiftinterfaces to be unparsable since the original type may not be declared in the module declaring the typealias.

Every CHECK line in this test that includes a reference to fully qualified type from the Original module represents an instance of this bug.

Once this behavior is corrected, it should be possible to succesfully parse UsesAliases.swiftinterface and the RUN: line for doing so should be uncommented.

…e written using typealiases from another module.

This test establishes a baseline for the behavior of swiftinterface emission when public declarations of all kinds reference typealiases from another module. It seems that for many types of declarations, the printer is looking through the typealias definition and printing the original type instead of a fully qualified reference to the typealias. This behavior can cause swiftinterfaces to be unparsable since the original type may not be declared in the module declaring the typealias.

Every CHECK line in this test that includes a reference to fully qualified type from the `Original` module represents an instance of this bug.

Once this behavior is corrected, it should be possible to succesfully parse `UsesAliases.swiftinterface` and the `RUN:` line for doing so should be uncommented.
@tshortli
Copy link
Contributor Author

@swift-ci please smoke test

@xymus
Copy link
Contributor

xymus commented Jul 21, 2022

@slavapestov @CodaFi Are you aware of this issue by chance? Or would you know what could make the compiler print the underlying type of typealiases when used in the context of generics, any, and some?

I think this issue has been present for a while now, it's affecting a decent number of swiftinterfaces.

@CodaFi
Copy link
Contributor

CodaFi commented Jul 21, 2022

CC @hborla

@hborla
Copy link
Member

hborla commented Jul 21, 2022

Or would you know what could make the compiler print the underlying type of typealiases when used in the context of generics, any, and some?

I'm aware of this behavior with any and it's due to #59041, which is a hack that we need to figure out how to solve in a different way.

…d errors about using `some` types when they might be unavailable.
@tshortli
Copy link
Contributor Author

@swift-ci please smoke test and merge

@swift-ci swift-ci merged commit e796ec7 into swiftlang:main Jul 22, 2022
@tshortli tshortli deleted the cross-module-typealias-tests branch July 22, 2022 18:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants