Skip to content

Conversation

@beccadax
Copy link
Contributor

In #86859, I modified the way export_as names are used in private module interfaces so that the export_as name is used when that module has been imported. This turns out to be slightly too aggressive in a specific scenario where a submodule of the export_as module imports a submodule of the real module—the compiler ends up using the export name even though the resulting lookup won’t actually work.

Modify the logic for deciding whether to use an exported module name so that it not only checks whether the export_as module has been loaded, but also whether the specific module or submodule the declaration belongs to is (possibly transitively) imported by that module.

Fixes rdar://167874630 (harder).

In swiftlang#86859, I modified the way `export_as` names are used in private module interfaces so that the `export_as` name is used when that module has been imported. This turns out to be slightly too aggressive in a specific scenario where a submodule of the export_as module imports a submodule of the real module—the compiler ends up using the export name even though the resulting lookup won’t actually work.

Modify the logic for deciding whether to use an exported module name so that it not only checks whether the export_as module has been loaded, but also whether the specific module or submodule the declaration belongs to is (possibly transitively) imported by that module.

Fixes rdar://167874630 (harder).
@beccadax
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@nkcsgexi nkcsgexi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the quick fix!

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.

2 participants