Issue 56128 segment id ice nightly#56143
Conversation
|
r? @varkor (rust_highfive has picked a reviewer for you, use r? to override) |
|
This comment has been minimized.
This comment has been minimized.
nrc
left a comment
There was a problem hiding this comment.
Did you mean to update the submodules?
LGTM otherwise
|
Er, no, no I did not. |
Without this, the `vis` does not wind up in the tree anywhere, and then we get ICEs because the node-ids it refers to are not present. The motivation seemed to be documentation, but `ListStem` HIR nodes are ignored in rustdoc, from what I can tell.
We are not mutating it now.
3440713 to
4c7ce7c
Compare
|
I guess though that this is fallout from the visibility change: |
|
I can make that code ignore |
|
I tried an alternate fix (use the vis for the last item) but it ice'd because the owner was wrong; more notes from discord here. I don't have a better idea than what's in this PR -- I leave it to @nrc and @petrochenkov to decide best course of action =) |
|
@bors: p=1 we're gonna want to backport this |
This comment has been minimized.
This comment has been minimized.
| // a re-export by accident when `pub`, e.g. in documentation. | ||
| let def = self.expect_full_def_from_use(id).next().unwrap_or(Def::Err); | ||
| let path = P(self.lower_path_extra(def, &prefix, ParamMode::Explicit, None)); | ||
| *vis = respan(prefix.span.shrink_to_lo(), hir::VisibilityKind::Inherited); |
There was a problem hiding this comment.
IIRC, you still need to reset at least pub (hir::VisibilityKind::Public) into something more private, otherwise you'll get a lot of noise from rustdoc (the stem is emitted for all braced imports).
This way the hack for UnreachablePub can be avoided as well.
This should be ok since hir::VisibilityKind::Public doesn't have a path with node IDs inside it.
There was a problem hiding this comment.
Everything except for VisibilityKind::Restricted can be reset to VisibilityKind::Inherited basically.
|
Beside #56143 (comment) everything looks reasonable. (I never fully understood what are relations between node ids, def ids, their owners, parents, etc though, and why @QuietMisdreavus had to do all those horrible things with them in #51425.) |
|
@bors r+ |
|
📌 Commit 5f2a173 has been approved by |
…y, r=petrochenkov Issue 56128 segment id ice nightly Tentative fix for #56128 From what I can tell, the problem is that if you have `pub(super) use foo::{a, b}`, then when we explode the `a` and `b`, the segment ids from the `super` path were not getting cloned. However, once I fixed *that*, then I ran into a problem that the "visibility" node-ids were not present in the final HIR -- this is because the visibility of the "stem" that is returned in this case was getting reset to inherited. I don't *think* it is a problem to undo that, so that the visibility is returned unmodified. Fixes #55475 Fixes #56128 cc @nrc @petrochenkov
|
☀️ Test successful - status-appveyor, status-travis |
[beta] Rollup backports * #56163: [master] Backport 1.30.1 release notes * #56147: resolve: Fix some asserts in import validation * #56118: Update books for Rust 2018 * #56117: resolve: Make "empty import canaries" invisible from other crates * #56065: Replace the ICEing on const fn loops with an error * #56143: Issue 56128 segment id ice nightly * #56134: Fix clippy documentation links (first in #56156) r? @ghost
Tentative fix for #56128
From what I can tell, the problem is that if you have
pub(super) use foo::{a, b}, then when we explode theaandb, the segment ids from thesuperpath were not getting cloned. However, once I fixed that, then I ran into a problem that the "visibility" node-ids were not present in the final HIR -- this is because the visibility of the "stem" that is returned in this case was getting reset to inherited. I don't think it is a problem to undo that, so that the visibility is returned unmodified.Fixes #55475
Fixes #56128
cc @nrc @petrochenkov