Ensure that Rustdoc discovers all necessary auto trait bounds
Fixes#50159
This commit makes several improvements to AutoTraitFinder:
* Call infcx.resolve_type_vars_if_possible before processing new
predicates. This ensures that we eliminate inference variables wherever
possible.
* Process all nested obligations we get from a vtable, not just ones
with depth=1.
* The 'depth=1' check was a hack to work around issues processing
certain predicates. The other changes in this commit allow us to
properly process all predicates that we encounter, so the check is no
longer necessary,
* Ensure that we only display predicates *without* inference variables
to the user, and only attempt to unify predicates that *have* an
inference variable as their type.
Additionally, the internal helper method is_of_param now operates
directly on a type, rather than taking a Substs. This allows us to use
the 'self_ty' method, rather than directly dealing with Substs.
If we end up with a projection predicate that equates a type with
itself (e.g. <T as MyType>::Value == <T as MyType>::Value), we can
run into issues if we try to add it to our ParamEnv.
Fixes#50159
This commit makes several improvements to AutoTraitFinder:
* Call infcx.resolve_type_vars_if_possible before processing new
predicates. This ensures that we eliminate inference variables wherever
possible.
* Process all nested obligations we get from a vtable, not just ones
with depth=1.
* The 'depth=1' check was a hack to work around issues processing
certain predicates. The other changes in this commit allow us to
properly process all predicates that we encounter, so the check is no
longer necessary,
* Ensure that we only display predicates *without* inference variables
to the user, and only attempt to unify predicates that *have* an
inference variable as their type.
Additionally, the internal helper method is_of_param now operates
directly on a type, rather than taking a Substs. This allows us to use
the 'self_ty' method, rather than directly dealing with Substs.
Check for negative impls when finding auto traits
Fixes#55321
When AutoTraitFinder begins examining a type, it checks for an explicit
negative impl. However, it wasn't checking for negative impls found when
calling 'select' on predicates found from nested obligations.
This commit makes AutoTraitFinder check for negative impls whenever it
makes a call to 'select'. If a negative impl is found, it immediately
bails out.
Normal users of SelectioContext don't need to worry about this, since
they stop as soon as an Unimplemented error is encountered. However, we
add predicates to our ParamEnv when we encounter this error, so we need
to handle negative impls specially (so that we don't try adding them to
our ParamEnv).
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#55321
When AutoTraitFinder begins examining a type, it checks for an explicit
negative impl. However, it wasn't checking for negative impls found when
calling 'select' on predicates found from nested obligations.
This commit makes AutoTraitFinder check for negative impls whenever it
makes a call to 'select'. If a negative impl is found, it immediately
bails out.
Normal users of SelectioContext don't need to worry about this, since
they stop as soon as an Unimplemented error is encountered. However, we
add predicates to our ParamEnv when we encounter this error, so we need
to handle negative impls specially (so that we don't try adding them to
our ParamEnv).
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.
