Fix intra-doc links for cross-crate re-exports of default trait methods#75176
Fix intra-doc links for cross-crate re-exports of default trait methods#75176bors merged 3 commits intorust-lang:masterfrom
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? |
Backtraceedit: 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 BacktraceNote that this happens all the way in |
The original fix for this was very simple: #58972 ignored
extern_traitsbecause 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_linkspass. There are also some minor changes inlibrustdoc/fold.rsto avoid borrowing theextern_traitsRefCell more than once at a time.However, that brought up a much more thorny problem.
rustc_resolvestarted 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 1builds the standard library and creates a sysrootcargo docdoes something likecargo checkto creatermetas for all the crates (unrelated to what was built above)cargo check-likelibcore-*.rmetais loaded as a transitive dependency and claims ownership of builtin macrosrustdoclater tries to resolve some path in a doc linklibcore-*.rlibis loaded and fails to claim ownership of builtin macrosrustc_resolvegives the error after step 5. However,rustdocdoesn't need suggestions at all -resolve_str_path_errorcompletely discards theResolutionError! The fix implemented in this PR is to skip the suggestion logic forresolve_ast_path: passrecord_used: falseand skiplookup_import_candidateswhenrecord_usedisn't set.It's possible that if/when #74207 is implemented this will need a more in-depth fix which returns a
ResolutionErrorfromcompile_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