-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
ICE when generating docs #46271
Comments
For reference: 5f44c65...e97ba83 |
Simplified repro, no dependency needed: pub fn x() {
extern crate core;
} |
Edit: I've inverted the failure condition when bisecting 😂 The actual regressing commit is e97ba83 #46115 @alexcrichton.
|
The issue here is likely due to the everybody-loops pass moved to a different place. Previously it was called immediately after phase 1, now it is called in the middle of phase 2. I'm now trying to see if putting it at the end of phase 2 would help. If not we'd put it back to the beginning of phase 2. Edit: neither is working. |
Also happens to https://github.com/alexcrichton/git2-rs |
@rust-lang/dev-tools @GuillaumeGomez Can we prioritize fixing this? It looks like a relatively widespread problem... |
Sure. Will take a look in the next days. |
Minimized: pub fn foo() {
extern crate std;
} I believe I see what's going on, will try to make a fix. |
Rustdoc has for some time now used the "everybody loops" pass in the compiler to avoid typechecking and otherwise avoid looking at implementation details. In rust-lang#46115 the placement of this pass was pushed back in the compiler to after macro expansion to ensure that it works with macro-expanded code as well. This in turn caused the regression in rust-lang#46271. The bug here was that the resolver was producing `def_id` instances for "possibly unused extern crates" which would then later get processed during typeck to actually issue lint warnings. The problem was that *after* resolution these `def_id` nodes were actually removed from the AST by the "everybody loops" pass. This later, when we tried to take a look at `def_id`, caused the compiler to panic. The fix applied here is a bit of a heavy hammer which is to just, in this one case, ignore the `extern crate` lints if the `def_id` looks "bogus" in any way (basically if it looks like the node was removed after resolution). The real underlying bug here is probably that the "everybody loops" AST pass is being stressed to much beyond what it was originally intended to do, but this should at least fix the ICE for now... Closes rust-lang#46271
I've posted a fix for this issue at #46405 |
rustc: Filter out bogus extern crate warnings Rustdoc has for some time now used the "everybody loops" pass in the compiler to avoid typechecking and otherwise avoid looking at implementation details. In rust-lang#46115 the placement of this pass was pushed back in the compiler to after macro expansion to ensure that it works with macro-expanded code as well. This in turn caused the regression in rust-lang#46271. The bug here was that the resolver was producing `def_id` instances for "possibly unused extern crates" which would then later get processed during typeck to actually issue lint warnings. The problem was that *after* resolution these `def_id` nodes were actually removed from the AST by the "everybody loops" pass. This later, when we tried to take a look at `def_id`, caused the compiler to panic. The fix applied here is a bit of a heavy hammer which is to just, in this one case, ignore the `extern crate` lints if the `def_id` looks "bogus" in any way (basically if it looks like the node was removed after resolution). The real underlying bug here is probably that the "everybody loops" AST pass is being stressed to much beyond what it was originally intended to do, but this should at least fix the ICE for now... Closes rust-lang#46271
On the latest nightly (e97ba83 2017-11-25) there's an ICE when generating the docs for the
atty
crate. Presumably somewhere along the line internal bookkeeping got confused and an invalidNodeId
was generated (or a valid one was deleted), resulting in a panic during the phase 3 analysis passes.It looks like this is a regression in the latest nightly because it was works just fine on the
(5f44c653c 2017-11-24)
build.Minimal Example:
This was on an up-to-date Arch Linux machine.
The text was updated successfully, but these errors were encountered: