Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It is possible to redundantly implement an auto trait for a trait-object type #56934

Closed
arielb1 opened this issue Dec 17, 2018 · 0 comments
Closed
Labels
A-trait-system Area: Trait system

Comments

@arielb1
Copy link
Contributor

arielb1 commented Dec 17, 2018

STR

#![feature(optin_builtin_traits)]

trait Xyz {}
auto trait Abc {}

impl Abc for dyn Xyz + Abc {
    
}

Expected Result

Code gives the same error as impl Xyz for dyn Xyz + Abc, giving error[E0371]: the object type (dyn Xyz + Abc + 'static)automatically implements the traitXyz`

Actual Result

Code passes coherence, but wfcheck fails because of the confusion:

error[E0283]: type annotations required: cannot resolve `(dyn Xyz + Abc + 'static): Abc`
 --> src/lib.rs:6:6
  |
6 | impl Abc for dyn Xyz + Abc {
  |      ^^^

error: aborting due to previous error
@arielb1 arielb1 added the A-trait-system Area: Trait system label Dec 17, 2018
@arielb1 arielb1 changed the title It is possible to redundantly implement an OIBIT for a trait-object type It is possible to redundantly implement an auto trait for a trait-object type Dec 17, 2018
arielb1 added a commit to arielb1/rust that referenced this issue Jan 14, 2019
This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.

Fixes rust-lang#56934
Centril added a commit to Centril/rust that referenced this issue Jan 15, 2019
…tsakis

forbid manually impl'ing one of an object type's marker traits

This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.

Fixes rust-lang#56934.

r? @nikomatsakis
Centril added a commit to Centril/rust that referenced this issue Jan 15, 2019
…tsakis

forbid manually impl'ing one of an object type's marker traits

This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.

Fixes rust-lang#56934.

r? @nikomatsakis
Centril added a commit to Centril/rust that referenced this issue Jan 15, 2019
…tsakis

forbid manually impl'ing one of an object type's marker traits

This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.

Fixes rust-lang#56934.

r? @nikomatsakis
VardhanThigle pushed a commit to jethrogb/rust that referenced this issue Jan 31, 2019
This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.

Fixes rust-lang#56934
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system
Projects
None yet
Development

No branches or pull requests

1 participant