Uh oh!
There was an error while loading. Please reload this page.
Always try to project predicates when finding auto traits in rustdoc - #60773
Merged
Conversation
Fixesrust-lang#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.
rust-highfive
commented
May 13, 2019
Contributor
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
hellow554
commented
May 13, 2019
Contributor
Would you mind reducing the testcase a little bit? pubstructTrue;pubstructFalse;pubtraitInterfaceType{typeSend;}pubstructFooInterface;pubstructDynTrait<I>(I);pubstructIntoIter(DynTrait<FooInterface>);implInterfaceTypeforFooInterface{typeSend = False;}unsafeimpl<I>SendforDynTrait<I>whereI:InterfaceType<Send = True>{} |
Dylan-DPC-zz
commented
May 20, 2019
ping from triage @eddyb waiting for your review on this |
eddyb
approved these changes
May 22, 2019
eddyb
left a comment
Contributor
There was a problem hiding this comment.
I'm a bit dubious on this whole module but AFAIK it only affects rustdoc right now.
eddyb
commented
May 22, 2019
Contributor
cc @rust-lang/wg-traits You might want to review this change at some point (and the whole module - maybe it can be simplified/deduplicated with other parts of the trait system?) @bors r+ |
bors
commented
May 22, 2019
Collaborator
📌 Commit 476ea9e has been approved by |
Centril added a commit
to Centril/rust
that referenced
this pull request
May 22, 2019
…r=eddyb Always try to project predicates when finding auto traits in rustdoc Fixesrust-lang#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.
bors added a commit
that referenced
this pull request
May 22, 2019
Rollup of 8 pull requests Successful merges: - #60300 (Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe) - #60773 (Always try to project predicates when finding auto traits in rustdoc) - #60809 (Add FAQ for NLL migration) - #61023 (Migrate from recursion to iterate on qualify consts visitor impl) - #61029 (Simplify RefCell minimum_spanning_tree example) - #61030 (Make maybe_codegen_consume_direct iterate instead of doing recursion) - #61034 (rustc_metadata: parametrize schema::CrateRoot by 'tcx and rip out old unused incremental infra.) - #61037 (Update clippy submodule) Failed merges: r? @ghost
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 {
field: *const T
}
has an implicit 'impl !Send for MyType', 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:
In this example, `::Project == True'
must hold for 'MyStruct: Send' to hold.
However, '::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.