This commit takes a different approach to add the `crate::` prefix to
item paths than previous commits. Previously, recursion was stopped
after a prelude crate name was pushed to the path. It is theorized that
this was the cause of the linking issues since the same path logic is
used for symbol names and that not recursing meant that details were
being missed that affect symbol names. As of this commit, instead of
ceasing recursion, a flag is passed through to any subsequent recursive
calls so that the same effect can be achieved by checking that flag.
In the 2018 edition, when suggesting traits to import that implement a
given method that is being invoked, suggestions will now include the
`crate::` prefix if the suggested trait is local to the current crate.
Rollup of 8 pull requests
Successful merges:
- #54564 (Add 1.29.1 release notes)
- #54567 (Include path in stamp hash for debuginfo tests)
- #54577 (rustdoc: give proc-macros their own pages)
- #54590 (std: Don't let `rust_panic` get inlined)
- #54598 (Remove useless lifetimes from `Pin` `impl`s.)
- #54604 (Added help message for `self_in_typedefs` feature gate)
- #54635 (Improve docs for std::io::Seek)
- #54645 (Compute Android gdb version in compiletest)
rustdoc: give proc-macros their own pages
related to https://github.com/rust-lang/rust/issues/49553 but i don't think it'll fix it
Currently, rustdoc doesn't expose proc-macros all that well. In the source crate, only their definition function is exposed, but when re-exported, they're treated as a macro! This is an awkward situation in all accounts. This PR checks functions to see whether they have any of `#[proc_macro]`, `#[proc_macro_attribute]`, or `#[proc_macro_derive]`, and exposes them as macros instead. In addition, attributes and derives are exposed differently than other macros, getting their own item-type, CSS class, and module heading.
Function-like proc-macros are lumped in with `macro_rules!` macros, but they get a different declaration block (i'm open to tweaking this, it's just what i thought of given how function-proc-macros operate):
Proc-macro attributes and derives get their own pages, with a representative declaration block. Derive macros also show off their helper attributes:
There's one wrinkle which this PR doesn't address, which is why i didn't mark this as fixing the linked issue. Currently, proc-macros don't expose their attributes or source span across crates, so while rustdoc knows they exist, that's about all the information it gets. This leads to an "inlined" macro that has absolutely no docs on it, and no `[src]` link to show you where it was declared.
The way i got around it was to keep proc-macro re-export disabled, since we do get enough information across crates to properly link to the source page:
Until we can get a proc-macro's docs (and ideally also its source span) across crates, i believe this is the best way forward.
overlook overflows in rustdoc trait solving
Context:
The new rustdoc "auto trait" feature walks across impls and tries to run trait solving on them with a lot of unconstrained variables. This is prone to overflows. These overflows used to cause an ICE because of a caching bug (fixed in this PR). But even once that is fixed, it means that rustdoc causes an overflow rather than generating docs.
This PR therefore adds a new helper that propagates the overflow error out. This requires rustdoc to then decide what to do when it encounters such an overflow: technically, an overflow represents neither "yes" nor "no", but rather a failure to make a decision. I've decided to opt on the side of treating this as "yes, implemented", since rustdoc already takes an optimistic view. This may prove to include too many items, but I *suspect* not.
We could probably reduce the rate of overflows by unifying more of the parameters from the impl -- right now we only seem to consider the self type. Moreover, in the future, as we transition to Chalk, overflow errors are expected to just "go away" (in some cases, though, queries might return an ambiguous result).
Fixes#52873
cc @QuietMisdreavus -- this is the stuff we were talking about earlier
cc @GuillaumeGomez -- this supersedes #53687
Proc-macros don't emit their attributes or source spans across crates.
This means that rustdoc can't actually see the docs of a proc-macro if
it wasn't defined in the active crate, and attempting to inline it
creates an empty page with no docs or source link. In lieu of attempting
to fix that immediately, this commit forces proc-macro re-exports to
never inline, which at least creates usable links to complete
documentation.
constraints:
- clean/inline.rs needs this map to fill in traits when inlining
- fold.rs needs this map to allow passes to fold trait items
- html/render.rs needs this map to seed the Cache.traits map of all
known traits
The first two are the real problem, since `DocFolder` only operates on
`clean::Crate` but `clean/inline.rs` only sees the `DocContext`. The
introduction of early passes means that these two now exist at the same
time, so they need to share ownership of the map. Even better, the use
of `Crate` in a rustc thread pool means that it needs to be Sync, so it
can't use `Lrc<Lock>` to manually activate thread-safety.
`parking_lot` is reused from elsewhere in the tree to allow use of its
`ReentrantMutex`, as the relevant parts of rustdoc are still
single-threaded and this allows for easier use in that context.
Rollup of 10 pull requests
Successful merges:
- #53418 (Mark some suggestions as MachineApplicable)
- #53431 (Moved some feature gate ui tests to correct location)
- #53442 (Update version of rls-data used with save-analysis)
- #53504 (Set applicability for more suggestions.)
- #53541 (Fix missing impl trait display as ret type)
- #53544 (Point at the trait argument when using unboxed closure)
- #53558 (Normalize source line and column numbers.)
- #53562 (Lament the invincibility of the Turbofish)
- #53574 (Suggest direct raw-pointer dereference)
- #53585 (Remove super old comment on function that parses items)
Failed merges:
- #53472 (Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.)
- #53563 (use String::new() instead of String::from(""), "".to_string(), "".to_owned() or "".into())
r? @ghost
Fix missing impl trait display as ret type
I need to convert a `TraitPredicate` into a `TraitBound` to get the returned impl trait. So far, didn't find how or even if it was the good way to do it.
cc @eddyb @oli-obk (since you're the one behind the change apparently 😉)
Rollup of 17 pull requests
Successful merges:
- #53030 (Updated RELEASES.md for 1.29.0)
- #53104 (expand the documentation on the `Unpin` trait)
- #53213 (Stabilize IP associated constants)
- #53296 (When closure with no arguments was expected, suggest wrapping)
- #53329 (Replace usages of ptr::offset with ptr::{add,sub}.)
- #53363 (add individual docs to `core::num::NonZero*`)
- #53370 (Stabilize macro_vis_matcher)
- #53393 (Mark libserialize functions as inline)
- #53405 (restore the page title after escaping out of a search)
- #53452 (Change target triple used to check for lldb in build-manifest)
- #53462 (Document Box::into_raw returns non-null ptr)
- #53465 (Remove LinkMeta struct)
- #53492 (update lld submodule to include RISCV patch)
- #53496 (Fix typos found by codespell.)
- #53521 (syntax: Optimize some literal parsing)
- #53540 (Moved issue-53157.rs into src/test/ui/consts/const-eval/)
- #53551 (Avoid some Place clones.)
Failed merges:
r? @ghost
