about summary refs log tree commit diff
path: root/src/test/rustdoc/issue-60726.rs
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-35/+0
2022-09-25rustdoc: update test cases now that code-header is used without in-bandMichael Howell-2/+2
2021-07-25Rustdoc accessibility: use real headers for doc itemsbors-2/+2
Part of #87059 Partially reverts #84703 Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
2021-06-02Update rustdoc testsGuillaume Gomez-4/+4
2021-04-19rustdoc: use details tag for trait implementorsJacob Hoffman-Andrews-2/+2
This switches from JS-generated toggles to using the HTML <details> tag for expanding and collapsing entries in the "Implementors" section.
2019-05-13Always try to project predicates when finding auto traits in rustdocAaron Hill-0/+35
Fixes #60726 Previous, AutoTraitFinder would only try to project predicates when the predicate type contained an inference variable. When finding auto traits, we only project to try to unify inference variables - we don't otherwise learn any new information about the required bounds. However, this lead to failing to properly generate a negative auto trait impl (indicating that a type never implements a certain auto trait) in the following unusual scenario: In almost all cases, a type has an (implicit) negative impl of an auto trait due some other type having an explicit *negative* impl of that auto trait. For example: struct MyType<T> { field: *const T } has an implicit 'impl<T> !Send for MyType<T>', due to the explicit negative impl (in libcore) 'impl<T: ?Sized> !Send for *const T'. However, as exposed by the 'abi_stable' crate, this isn't always the case. This minimzed example shows how a type can never implement 'Send', due to a projection error: ``` pub struct True; pub struct False; pub trait MyTrait { type Project; } pub struct MyStruct<T> { field: T } impl MyTrait for u8 { type Project = False; } unsafe impl<T> Send for MyStruct<T> where T: MyTrait<Project=True> {} pub struct Wrapper { inner: MyStruct<u8> } ``` In this example, `<u8 as MyTrait>::Project == True' must hold for 'MyStruct<u8>: Send' to hold. However, '<u8 as MyTrait>::Project == False' holds instead To properly account for this unusual case, we need to call 'poly_project_and_unify' on *all* predicates, not just those with inference variables. This ensures that we catch the projection error that occurs above, and don't incorrectly determine that 'Wrapper: Send' holds.