-
Notifications
You must be signed in to change notification settings - Fork 1.8k
fix: Fix associated item visibility in block-local impls #14176
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
Conversation
let def_map = id.def_map(db.upcast()); | ||
let origin = def_map[id.local_id].origin; | ||
if matches!(origin, ModuleOrigin::BlockExpr { .. }) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a simpler way to check whether a hir::Module
is a block? I thought I could do better but failed badly...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the ModuleId
contained in a hir::Module
has a block
field that's set when its a block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
block
is also set for a non-block module defined inside a block module, because it's derived from a DefMap
for block module. It is rare but I'd like to support as much as possible unless it breaks our incremental model.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, then I think this is the appropriate way
1c89ead
to
d416623
Compare
@bors r+ |
Fix associated item visibility in block-local impls Fixes #14046 When we're resolving visibility of block-local items... > `self` normally refers to the containing non-block module, and `super` to its parent (etc.). However, visibilities must only refer to a module in the DefMap they're written in, so we restrict them when that happens. ([link]) ...unless we're resolving visibility of associated items in block-local impls, because that impl is semantically "hoisted" to the nearest (non-block) module. With this PR, we skip the adjustment for such items. Since visibility representation of those items is modified, this PR also adjusts visibility rendering in `HirDisplay`. [link]: https://github.com/rust-lang/rust-analyzer/blob/a6603fc21d50b3386a488c96225b2d1fd492e533/crates/hir-def/src/nameres/path_resolution.rs#L101-L103
💔 Test failed - checks-actions |
The tests are failing because we fail to render constant tuples (consteval seems fine, only rendering is the problem). @HKalbasi Can we add support for tuples in |
@bors r=Veykril |
💡 This pull request was already approved, no need to approve it again.
|
☀️ Test successful - checks-actions |
Fixes #14046
When we're resolving visibility of block-local items...
...unless we're resolving visibility of associated items in block-local impls, because that impl is semantically "hoisted" to the nearest (non-block) module. With this PR, we skip the adjustment for such items.
Since visibility representation of those items is modified, this PR also adjusts visibility rendering in
HirDisplay
.