Choose predicates without inference variables over those with them
Fixes#54705
When constructing synthetic auto trait impls, we may come across
multiple predicates involving the same type, trait, and substitutions.
Since we can only display one of these, we pick the one with the 'most
strict' lifetime paramters. This ensures that the impl we render the
user is actually valid (that is, a struct matching that impl will
actually implement the auto trait in question).
This commit exapnds the definition of 'more strict' to take into account
inference variables. We always choose a predicate without inference
variables over a predicate with inference variables.
test that rustdoc doesn't overflow on a big enum
Adds a test to close#25295. The test case depended on `enum_primitive` so I just basically pulled its source into an auxiliary file, is that the right way to do it?
Add index page argument
@Mark-Simulacrum: I might need some help from you: in bootstrap, I want to add an argument (a new flag added into `rustdoc`) in order to generate the current index directly when `rustdoc` is documenting the `std` lib. However, my change in `bootstrap` didn't do it and I assume it must be moved inside the `Std` struct. But there, I don't see how to pass it to `rustdoc` through `cargo`. Did I miss anything?
r? @QuietMisdreavus
Fixes#54705
When constructing synthetic auto trait impls, we may come across
multiple predicates involving the same type, trait, and substitutions.
Since we can only display one of these, we pick the one with the 'most
strict' lifetime paramters. This ensures that the impl we render the
user is actually valid (that is, a struct matching that impl will
actually implement the auto trait in question).
This commit exapnds the definition of 'more strict' to take into account
inference variables. We always choose a predicate without inference
variables over a predicate with inference variables.
Rollup of 21 pull requests
Successful merges:
- #54816 (Don't try to promote already promoted out temporaries)
- #54824 (Cleanup rustdoc tests with `@!has` and `@!matches`)
- #54921 (Add line numbers option to rustdoc)
- #55167 (Add a "cheap" mode for `compute_missing_ctors`.)
- #55258 (Fix Rustdoc ICE when checking blanket impls)
- #55264 (Compile the libstd we distribute with -Ccodegen-unit=1)
- #55271 (Unimplement ExactSizeIterator for MIR traversing iterators)
- #55292 (Macro diagnostics tweaks)
- #55298 (Point at macro definition when no rules expect token)
- #55301 (List allowed tokens after macro fragments)
- #55302 (Extend the impl_stable_hash_for! macro for miri.)
- #55325 (Fix link to macros chapter)
- #55343 (rustbuild: fix remap-debuginfo when building a release)
- #55346 (Shrink `Statement`.)
- #55358 (Remove redundant clone (2))
- #55370 (Update mailmap for estebank)
- #55375 (Typo fixes in configure_cmake comments)
- #55378 (rustbuild: use configured linker to build boostrap)
- #55379 (validity: assert that unions are non-empty)
- #55383 (Use `SmallVec` for the queue in `coerce_unsized`.)
- #55391 (bootstrap: clean up a few clippy findings)
Report const eval error inside the query
Functional changes: We no longer warn about bad constants embedded in unused types. This relied on being able to report just a warning, not a hard error on that case, which we cannot do any more now that error reporting is consistently centralized.
r? @RalfJung
fixes#53561
Fix Rustdoc ICE when checking blanket impls
Fixes#55001, #54744
Previously, SelectionContext would unconditionally cache the selection
result for an obligation. This worked fine for most users of
SelectionContext, but it caused an issue when used by Rustdoc's blanket
impl finder.
The issue occured when SelectionContext chose a ParamCandidate which
contained inference variables. Since inference variables can change
between calls to select(), it's not safe to cache the selection result -
the chosen candidate might not be applicable for future results, leading
to an ICE when we try to run confirmation.
This commit prevents SelectionContext from caching any ParamCandidate
that contains inference variables. This should always be completely
safe, as trait selection should never depend on a particular result
being cached.
I've also added some extra debug!() statements, which I found helpful in
tracking down this bug.
Fixes#55001, #54744
Previously, SelectionContext would unconditionally cache the selection
result for an obligation. This worked fine for most users of
SelectionContext, but it caused an issue when used by Rustdoc's blanket
impl finder.
The issue occured when SelectionContext chose a ParamCandidate which
contained inference variables. Since inference variables can change
between calls to select(), it's not safe to cache the selection result -
the chosen candidate might not be applicable for future results, leading
to an ICE when we try to run confirmation.
This commit prevents SelectionContext from caching any ParamCandidate
that contains inference variables. This should always be completely
safe, as trait selection should never depend on a particular result
being cached.
I've also added some extra debug!() statements, which I found helpful in
tracking down this bug.
Fix spelling in the documentation to htmldocck.py
I was reading through htmldocck.py, and decided to attempt to clean it up a little bit. Let me know if you disagree with my edits.
The link that is matched against is not the same as would be generated by
rustdoc. We should also check that the `foo/private` directory is not generated
at all.
The generated code would look like `<code>impl <a href="...">Foo</a></code>`
which the plain text matcher doesn't match. But by using the XPATH notation, the
nodes are flattened and we can correctly assert that `impl Foo` does not occur
in the generated docs.
The Auto Trait Implementation section is not wrapped in a
`synthetic-implementations` class. In fact, it is wrapped in a
`synthetic-implementations` id. However, we can generalize and completely remove
the `synthetic-implementations` requirement. We just have to verify that there's
no mention of "Auto Trait Implementations" anywhere.
Struct names are no longer encapsulated in `<code>` tags, which meant that the
test was not correctly verifying that it wasn't being show. I've also added a
check to make sure the documentation page for the redirect::Qux struct is not
generated at all.
The `@!has` command does not support specifying just a PATH and an XPATH. That
means that the previous test searched for the literal string
`//h2[@id="implementations"]` within the generated output, which obviously
didn't exist. Even after adding a trait implementation, the test still passed.
The correct way to check for the existence of a DOM element with the id
`implementations` is to use the `@count` keyword.
"Run" links to the playground are not added to the generated documentation if
the unstable `--playground-url` argument is not passed to rustdoc. Therefore,
without specifying `--playground-url` as a compile-flag, the test doesn't
correctly assert that `#![doc(html_playground_url = "")]` removes playground
links.
The old test was supposed to check for proper html escaping when showing the
contents of constants. This was changed as part of #53409. The revised test
asserts that the contents of the constant is not shown as part of the generated
documentation.
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
