Code change:
EDIT(camelid): This issue is now being used to track a different, but related, bug. The discussion starting is current. <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --- Clone . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this is probably related to somehow. I don't plan to investigate any of the proximate issues until the underlying problem is fixed. Feel free to take a look yourself if this is blocking your work, but it won't be easy.
Oh, I guess this could also be a missed case from That should be easier to fix.
If you can come up with an MCVE it would be easier to tell which of the two issues it is.
Not exactly an MCVE, but I think I'm able to reproduce this with only a handful of files The line does change slightly though: (Same rustc version output as above). Hope this helps :). Best, Mautamu
I think the issue is that the crate is first used in a dependency, so it isn't loaded in Maybe a fix is to recursively traverse the docs of re-exports? That sounds kind of expensive, but the only other option (besides fixing ) is to revert and re-open
An easy workaround is to link to somewhere in the crate re-exporting the docs, even something like this would work:
Hmm, this setup didn't reproduce the issue, not sure why:
Maybe the proc macro is related somehow?
Regression in searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThat's , good guess,
This regression now slipped into beta 1.53.0.
came up with a slightly smaller reproduction, the proc macro wasn't related:
We've also run into this recently with a rather trivial crate
This is likely to hit stable, as no beta-accepted patch appears available at this time.
Is there an easy way to help bisect to figure out which PR to revert, or otherwise help along this issue? It’d be somewhat sad for our five-method create to not have docs even on stable.
you can use the workaround I mentioned at the top: is the PR to revert; I'm not wholly opposed to doing so but it means reintroducing other regressions. See .
This now occurs on stable and should likely be tagged , I assume.
A note to others who stumble upon this, the workaround in works great; to figure out which crate(s) you need to list, run: Look for the last log message before the panic — in my case, that was: Adding fixed the problem.
should give you a lot less logging and still show the right crate.
Further minimized from and turned into a rustdoc test form:
thanks for the reduction, that helped a lot. The problem is that rustdoc is considering each line on its own, when it should be considering the whole documentation for the item at once: When there's a reference link, rustdoc will see the link text instead of the link target: The fix is to use in instead of visiting each attribute one by one.
I experienced this same issue today on 1.56 stable despite the fix. The log followed the same pattern as above when run with . Removing this dependency fixed the problem:
can you post a link to the code that caused the ICE?
cc
reports the same issue in an open source codebase:
Also seeing this in another project in 1.56 stable. Would put together a reproducer but there already is one.
If you could minimize the crash that would be helpful, the one at the top was already fixed by
I've reduced it to Still seems a bit large but having trouble getting it any smaller. This reproducer involves I suspect that is the root cause in this case, not sure if that tracks with the other reports.
how can I build that package? running gives me even though I have gcc installed.
The dependency is macOS only. GitHub runners can do it. There is probably a way to shrink the dependency enough to build on some other platform, can look into it a bit more
Updated to ICE on windows, which I suspect is enough for linux as well. May require or
Hmm, so something strange is going on here - I example a little more, down to four local crates: If has the contents of , then the issue reproduces correctly, but if it's anything smaller, then documents fine. At first I suspected the crate hash was different or something, but cargo is passing different hashes even when and are identical, so that's not it.
FWIW you can work around the ICE with this diff:
Really interesting workaround! Those ought to be the same due to , maybe there’s some interaction there?
see
MCVE:

Related discussion:
text: let old_mod = mem::replace(&mut self.current_mod, new_mod); self.load_links_in_attrs(&item.attrs, item.span); <del> ast::visit::walk_item(self, item); </del> <ins> visit::walk_item(self, item); </ins> self.current_mod = old_mod; } else { self.load_links_in_attrs(&item.attrs, item.span); <del> ast::visit::walk_item(self, item); </del> <ins> visit::walk_item(self, item); </ins> } } <ins> // NOTE: if doc-comments are ever allowed on function parameters, this will have to implement `visit_param` too. fn visit_assoc_item(&mut self, item: &ast::AssocItem, ctxt: visit::AssocCtxt) { self.load_links_in_attrs(&item.attrs, item.span); visit::walk_assoc_item(self, item, ctxt) } fn visit_field_def(&mut self, field: &ast::FieldDef) { self.load_links_in_attrs(&field.attrs, field.span); visit::walk_field_def(self, field) } fn visit_variant(&mut self, v: &ast::Variant) { self.load_links_in_attrs(&v.attrs, v.span); visit::walk_variant(self, v) } </ins> }