resolve: fix bug in visibility of shadowed use declarations #30294
Conversation
…e in one namespace (e.g. the value namespace) is overridden by a later use declaration defining the same name in the other namespace (e.g. the type namespace).
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
cc #30159. |
|
r? @nrc |
|
This also fixes #30159. |
| match import_resolution.target_for_namespace(ns) { | ||
| Some(target) => { | ||
| if !import_resolution[ns].is_public { | ||
| continue; |
There was a problem hiding this comment.
should this be a labelled continue? It looks like you should continue to the next import_resolution, not to the next namespace
There was a problem hiding this comment.
No, if the import resolution is not public in one namespace it still could be public in the other namespace. For example, consider
mod foo {}
pub fn f() {}
use foo as bar;
pub use f as bar;Here, there is a single import_resolution corresponding to bar that is private in the type namespace (i.e. !import_resolution[TypeNS].is_public) but public in the value namespace (i.e. import_resolution[ValueNS].is_public). If we skipped to the next import_resolution after seeing that the type namespace is private, we would not export bar in the value namespace.
|
LGTM, modulo the two comments |
|
@nrc Thanks for the feedback. I addressed both comments. |
|
Sounds good, thanks! @bors: r+ |
|
📌 Commit ada87fa has been approved by |
This fixes a bug in which the visibility of a use declaration defining a name in one namespace (e.g. the value namespace) is overridden by a later use declaration defining the same name in the other namespace (e.g. the type namespace). For example,
```rust
fn f() {}
pub mod bar {}
mod foo {
use f; // This import should not be visible outside `foo`,
pub use bar as f; // but it visible outside of `foo` because of this import.
}
fn main() { foo::f(); }
```
As the example demonstrates, this is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by correcting visibility modifiers.
…to avoid breakage.
r? @nrc Since PR #30294 unintentionally fixed issue #30159, it can cause breakage for a different reason than I originally stated in the PR (see #30159, I characterized the issue precisely there). This commit limits the scope of the breakage to what I originally stated in the PR by "unfixing" the backwards incompatible part of #30159. I think fixing #30159 has enough potential for breakage to warrant a crater run. If you disagree, I can cancel this PR, leaving it fixed.
jseyfried
changed the title
This fixes a bug in which the visibility of a use declaration defining a name in one namespace (e.g. the value namespace) is overridden by a later use declaration defining the same name in the other namespace (e.g. the type namespace). For example,
As the example demonstrates, this is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by correcting visibility modifiers.