-
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
Fix intra-doc links for cross-crate re-exports of default trait methods #75176
Conversation
This comment has been minimized.
This comment has been minimized.
A strange error... |
I think this is because of the change to |
Update: that did not help :( Maybe the error shows up because rustdoc is doing more work than before and ran into some edge case from #73566? |
Backtrace
edit: so I remember next time, the way to get this backtrace is with |
The error comes from here: rust/src/librustc_resolve/macros.rs Lines 1077 to 1087 in e539dd6
Note that it uses There are a bunch of other questions that pop up, like
|
I think this might be because we clone the |
Just trying to print the DefId causes a panic. diff --git a/src/librustc_resolve/build_reduced_graph.rs b/src/librustc_resolve/build_reduced_graph.rs
index 11c7793b3ad..afce46395a9 100644
--- a/src/librustc_resolve/build_reduced_graph.rs
+++ b/src/librustc_resolve/build_reduced_graph.rs
@@ -164,7 +164,10 @@ impl<'a> Resolver<'a> {
}
let ext = Lrc::new(match self.cstore().load_macro_untracked(def_id, &self.session) {
- LoadedMacro::MacroDef(item, edition) => self.compile_macro(&item, edition),
+ LoadedMacro::MacroDef(item, edition) => {
+ debug!("loading macro {} with DefId {:?}", item.ident.name, def_id);
+ self.compile_macro(&item, edition)
+ }
LoadedMacro::ProcMacro(ext) => ext,
});
|
This is the same panic as from #66159 |
@kinnison how hard do you think it would be to add the whole resolver to the |
@petrochenkov is the person to ask, but I suspect the answer is no. |
It turns out this is a known issue. #68427 |
Current status: I still think this is because of cloning the resolver somehow, but I haven't figured out exactly why it's giving an error. So there might be some hack I could pile on top of #66211 that doesn't require rewriting half of rustdoc. I want to figure out the current issue before I go chasing too many windmills. |
r=me after removing all the added debugging stuff (at least in resolve) |
…olution This avoids a rare rustdoc bug where loading `core` twice caused a 'cannot find a built-in macro' error: 1. `x.py build --stage 1` builds the standard library and creates a sysroot 2. `cargo doc` does something like `cargo check` to create `rmeta`s for all the crates (unrelated to what was built above) 3. the `cargo check`-like `libcore-*.rmeta` is loaded as a transitive dependency *and claims ownership* of builtin macros 4. `rustdoc` later tries to resolve some path in a doc link 5. suggestion logic fires and loads "extern prelude" crates by name 6. the sysroot `libcore-*.rlib` is loaded and *fails to claim ownership* of builtin macros This fixes step 5. by not running suggestion logic if this is a speculative resolution. Additionally, it marks `resolve_ast_path` as a speculative resolution.
📌 Commit 9131d23 has been approved by |
The 'check' failure is spurious:
Hopefully bors succeeds. |
☀️ Test successful - checks-actions, checks-azure |
…petrochenkov Give a better error message for duplicate built-in macros Minor follow-up to rust-lang#75176 giving a better error message for duplicate builtin macros. This would have made it a little easier to debug. r? @petrochenkov
…r=jyn514 Use more intra-doc-links in `core::fmt` This is a follow-up to rust-lang#75819, which encountered some broken links due to rust-lang#75176, so this PR contains the links that are blocked on rust-lang#75176. r? @jyn514
This change causes the same error: diff --git a/library/std/src/lib.rs b/library/std/src/lib.rs
index 39b0ca63301..e97d77a1eb2 100644
--- a/library/std/src/lib.rs
+++ b/library/std/src/lib.rs
@@ -338,6 +338,8 @@
#[allow(unused)]
use prelude::v1::*;
+extern crate self as std;
+
// Access to Bencher, etc.
#[cfg(test)]
extern crate test; The use case for this is allowing Backtrace
Note that this happens all the way in |
The original fix for this was very simple: #58972 ignored
extern_traits
because before #65983 was fixed, they would always fail to resolve, giving spurious warnings. So the first commit just undoes that change, so extern traits are now seen by thecollect_intra_doc_links
pass. There are also some minor changes inlibrustdoc/fold.rs
to avoid borrowing theextern_traits
RefCell more than once at a time.However, that brought up a much more thorny problem.
rustc_resolve
started giving 'error: cannot find a built-in macro with namecfg
' when documentinglibproc_macro
(I still haven't been able to reproduce on anything smaller than the full standard library). The chain of events looked like this (thanks @eddyb for the help debugging!):x.py build --stage 1
builds the standard library and creates a sysrootcargo doc
does something likecargo check
to creatermeta
s for all the crates (unrelated to what was built above)cargo check
-likelibcore-*.rmeta
is loaded as a transitive dependency and claims ownership of builtin macrosrustdoc
later tries to resolve some path in a doc linklibcore-*.rlib
is loaded and fails to claim ownership of builtin macrosrustc_resolve
gives the error after step 5. However,rustdoc
doesn't need suggestions at all -resolve_str_path_error
completely discards theResolutionError
! The fix implemented in this PR is to skip the suggestion logic forresolve_ast_path
: passrecord_used: false
and skiplookup_import_candidates
whenrecord_used
isn't set.It's possible that if/when #74207 is implemented this will need a more in-depth fix which returns a
ResolutionError
fromcompile_macro
, to allow rustdoc to reuse the suggestions from rustc_resolve. However, that's a much larger change and there's no need for it yet, so I haven't implemented it here.Fixes #73829.
r? @GuillaumeGomez