rustdoc: use --static-root-path for settings.js
At the time i was writing https://github.com/rust-lang/docs.rs/pull/332, i noticed that the `settings.js` file that was being loaded was not being loaded from the `--static-root-path`. This PR fixes that so that users on docs.rs can effectively cache this file.
rustdoc: don't process `Crate::external_traits` when collecting intra-doc links
Part of https://github.com/rust-lang/rust/issues/58745, closes https://github.com/rust-lang/rust/pull/58917
The `collect-intra-doc-links` pass keeps track of the modules it recurses through as it processes items. This is used to know what module to give the resolver when looking up links. When looking through the regular items of the crate, this works fine, but the `DocFolder` trait as written doesn't just process the main crate hierarchy - it also processes the trait items in the `external_traits` map. This is useful for other passes (so they can strip out `#[doc(hidden)]` items, for example), but here it creates a situation where we're processing items "outside" the regular module hierarchy. Since everything in `external_traits` is defined outside the current crate, we can't fall back to finding its module scope like we do with local items.
Skipping this collection saves us from emitting some spurious warnings. We don't even lose anything by skipping it, either - the docs loaded from here are only ever rendered through `html::render::document_short` which strips any links out, so the fact that the links haven't been loaded doesn't matter. Hopefully this removes most of the remaining spurious resolution warnings from intra-doc links.
r? @GuillaumeGomez
- Makes the warning part of the `intra_doc_link_resolution_failure`
lint.
- Tightens the span to just the ambiguous link.
- Reports ambiguities across all three namespaces.
- Uses structured suggestions for disambiguation.
- Adds a test for the warnings.
Modify doctest's auto-`fn main()` to allow `Result`s
This lets the default `fn main()` ~~return `impl Termination`~~ unwrap Results, which allows the use of `?` in most tests without adding it manually. This fixes#56260
~~Blocked on `std::process::Termination` stabilization.~~
Using `Termination` would have been cleaner, but this should work OK.
Rustdoc remove old style files
Reopening of #56577 (which I can't seem to reopen...).
I made the flag unstable so with this change, what was blocking the PR is now gone I assume.
Ignore future deprecations in #[deprecated]
The future deprecation warnings should only apply to `#[rustc_deprecated]` as they take into account rustc's version. Fixes#57952.
I've also slightly modified rustdoc's display of future deprecation notices to make it more consistent, so I'm assigning a rustdoc team member for review to make sure this is okay.
r? @GuillaumeGomez
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
rustdoc: overhaul code block lexing errors
Fixes#53919.
This PR moves the reporting of code block lexing errors from rendering time to an early pass, so we can use the compiler's error reporting mechanisms. This dramatically improves the diagnostics in this situation: we now de-emphasize the lexing errors as a note under a warning that has a span and suggestion instead of just emitting errors at the top level.
Additionally, this PR generalizes the markdown -> source span calculation function, which should allow other rustdoc warnings to use better spans in the future.
Last, the PR makes sure that the code block is always emitted in the docs, even if it fails to highlight correctly.
Of note:
- The new pass unfortunately adds another pass over the docs to gather the doc blocks for syntax-checking. I wonder if this could be combined with the pass that looks for testable blocks? I'm not familiar with that code, so I don't know how feasible that is.
- `pulldown_cmark` doesn't make it easy to find the spans of the code blocks, so the code that calculates the spans is a little nasty. It works for all the test cases I threw at it, but I wouldn't be surprised if an edge case would break it. Should have a thorough review.
- This PR worsens the state of #56885, since those certain fatal lexing errors are now emitted before docs get generated at all.
Fix stack overflow when finding blanket impls
Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.
To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.
Fixes#56701
I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
