-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ICE: "fully private item in the table" when compiling bacon v2.2.5 #104539
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
Comments
@rustbot label +T-compiler +I-ICE |
I understand why this happens - parent import in an import chain can have a smaller visibility that the it's child's private visibility, so the equality condition in https://github.com/rust-lang/rust/blob/master/compiler/rustc_resolve/src/effective_visibilities.rs#L141-L144 fails and doesn't prune this case, and it ends up being in the table even despite being private. However, I couldn't construct a minimized example for a test. |
Fixed in #104546. |
I'd love to help but I have zero expertise with the part of the compiler that has trouble here, the codebase in question, or minimizing by hand, which I could use to produce a minimized version. I found this by blindly turning on all the debug checks and reinstalling all my utilities. |
privacy: Fix more (potential) issues with effective visibilities Continuation of rust-lang#103965. See individual commits for more detailed description of the changes. The shortcuts removed in rust-lang@4eb63f6 and rust-lang@c7c7d16 could actually be correct (or correct after some tweaks), but they used global reasoning like "we can skip this update because if the code compiles then some other update should do the same thing eventually". I have some expertise in this area, but I still have doubt whether such global reasoning was correct or not, especially in presence of all possible exotic cases with imports. After this PR all table changes should be "locally correct" after every update, even if it may be overcautious. If similar optimizations are introduced again they will need detailed comments explaining why it's legal to do what they do and providing proofs. Fixes rust-lang#104249. Fixes rust-lang#104539.
privacy: Fix more (potential) issues with effective visibilities Continuation of rust-lang/rust#103965. See individual commits for more detailed description of the changes. The shortcuts removed in rust-lang/rust@4eb63f6 and rust-lang/rust@c7c7d16 could actually be correct (or correct after some tweaks), but they used global reasoning like "we can skip this update because if the code compiles then some other update should do the same thing eventually". I have some expertise in this area, but I still have doubt whether such global reasoning was correct or not, especially in presence of all possible exotic cases with imports. After this PR all table changes should be "locally correct" after every update, even if it may be overcautious. If similar optimizations are introduced again they will need detailed comments explaining why it's legal to do what they do and providing proofs. Fixes rust-lang/rust#104249. Fixes rust-lang/rust#104539.
privacy: Fix more (potential) issues with effective visibilities Continuation of rust-lang/rust#103965. See individual commits for more detailed description of the changes. The shortcuts removed in rust-lang/rust@4eb63f6 and rust-lang/rust@c7c7d16 could actually be correct (or correct after some tweaks), but they used global reasoning like "we can skip this update because if the code compiles then some other update should do the same thing eventually". I have some expertise in this area, but I still have doubt whether such global reasoning was correct or not, especially in presence of all possible exotic cases with imports. After this PR all table changes should be "locally correct" after every update, even if it may be overcautious. If similar optimizations are introduced again they will need detailed comments explaining why it's legal to do what they do and providing proofs. Fixes rust-lang/rust#104249. Fixes rust-lang/rust#104539.
I can't reproduce this on nightly, but I can reproduce it on a toolchain I keep up to date with
master
that is built with debug assertions:rustc --version --verbose
:Backtrace
The text was updated successfully, but these errors were encountered: