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.

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

Revisit the visibility check in type_resolve #6840

Open
jjcnn opened this issue Jan 17, 2025 · 0 comments
Open

Revisit the visibility check in type_resolve #6840

jjcnn opened this issue Jan 17, 2025 · 0 comments
Labels
compiler: collection Everything to do with graph collection, type collection, and the collection context. compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen

Comments

@jjcnn
Copy link
Contributor

jjcnn commented Jan 17, 2025

The function resolve_call_path in type_resolve.rs in some cases performs a visibility check of the path being resolved. However, the visibility check is insufficient, because the prefixes of the path are only checked for visibility if the prefix refers to a module.

For example, for the path MyPackage::MyModule::MySubmodule::MyEnum::MyEnumVariant we do not check the visibility of MyEnum, since this identifier refers to an enum rather than to a module.

Note that accessing a private item is legal if the access is performed through a reexport, so it is not entirely trivial to solve this problem.

@jjcnn jjcnn added compiler: collection Everything to do with graph collection, type collection, and the collection context. compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen labels Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler: collection Everything to do with graph collection, type collection, and the collection context. compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen
Projects
None yet
Development

No branches or pull requests

1 participant