| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
The order of the `where` bounds on auto trait impls changed because
rustdoc currently sorts auto trait `where` bounds based on the `Debug`
output for the bound. Now that the bounds have an actual `Res`, they are
being unintentionally sorted by their `DefId` rather than their path.
So, I had to update a test for the change in ordering of the rendered
bounds.
|
|
Part of #87059
Partially reverts #84703
Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
|
|
|
|
This switches from JS-generated toggles to using the HTML <details> tag
for expanding and collapsing entries in the "Implementors" section.
|
|
They were originally called "opt-in, built-in traits" (OIBITs), but
people realized that the name was too confusing and a mouthful, and so
they were renamed to just "auto traits". The feature flag's name wasn't
updated, though, so that's what this PR does.
There are some other spots in the compiler that still refer to OIBITs,
but I don't think changing those now is worth it since they are internal
and not particularly relevant to this PR.
Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
|
|
Fixes #72213
Any predicates in the param env are guaranteed to hold, so we don't need
to do any additional processing of them if we come across them as
sub-obligations of a different predicate. This allows us to avoid adding
the same predicate to the computed ParamEnv multiple times (but with
different regions each time), which causes an ambiguity error during
fulfillment.
|
|
|
|
|
|
Previously we would only generate a list of synthetic implementations
for two well known traits – Send and Sync. With this patch all the auto
traits known to rustc are considered. This includes such traits like
Unpin and user’s own traits.
Sadly the implementation still iterates through the list of crate items
and checks them against the traits, which for non-std crates containing
their own auto-traits will still not include types defined in std/core.
It is an improvement nontheless.
|
|
|
|
|
|
Simplified foreign type rendering by switching from tables to flexbox. Also, removed some seemingly extraneous elements like “ghost” spans.
Reduces element count on std::iter::Iterator by 30%.
|
|
|
|
|
|
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.
|
|
|
|
|
|
While the order of the where clauses was deterministic, the
ordering of bounds and lifetimes was not. This made the order flip-
flop randomly when new traits and impls were added to libstd.
This PR makes the ordering of bounds and lifetimes deterministic,
and re-enables the test that was causing the issue.
Fixes #49123
|
|
|
|
|
|
|
|
|
|
This removes the implicit dependency on the iteration
order of FxHashMap
|
|
|
|
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
|
