-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 documenting code with intra-doc-links with types with the same name but different crates #66159
Comments
So the explosion is that somehow the crate index in the Interestingly if you add Edit: So this looks like it's somehow a bug when trying to resolve it as a global name (both |
Maybe it's linked to #65840 ? If so, it's not in rustdoc but below. |
I believe I've worked out approximately what's going on: Rustdoc freezes the compiler state (resolver, etc) as part of the setup to ready the Since It feels like the moment a It's also possible that rustdoc could be forced to enter the right context so that we never do this wrongly, but that's beyond me right now. Given that, @GuillaumeGomez , I feel this is probably either a bug in how |
My gut feeling is that we probably need to stop capturing/cloning the resolver as we do here: https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs#L346 and instead try and find a resolver as part of the closure here: https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs#L354 Of course, it looks like a |
I wonder why that type can be cloned in the first place... |
Fix ICE when documentation includes intra-doc-link When collecting intra-doc-links we could trigger the loading of extra crates into the crate store due to name resolution finding crates referred to in documentation but not in code. This might be due to configuration differences or simply referring to something else. This would cause an ICE because the newly loaded crate metadata existed in a crate store associated with the rustdoc global context, but the resolver had its own crate store cloned just before the documentation processing began and as such it could try and look up crates in a store which lacked them. In this PR, I add support for `--extern-private` to the `rustdoc` tool so that it is supported for `compiletest` to then pass the crates in; and then I fix the issue by forcing the resolver to look over all the crates before we then lower the input ready for processing into documentation. The first commit (the `--extern-private`) could be replaced with a commit which adds support for `--extern` to `compiletest` if preferred, though I think that adding `--extern-private` to `rustdoc` is more useful anyway since it makes the CLI a little more like `rustc`'s which might help reduce surprise for someone running it by hand or in their own test code. The PR is meant to fix #66159 though it may also fix #65840. cc @GuillaumeGomez
Cargo.toml
src/lib.rs
//! a [`Backtrace`] b [`backtrace::Backtrace`] c
/cc @kinnison
The text was updated successfully, but these errors were encountered: