nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-27 09:14:20 +00:00
Code Issues Packages Projects Releases Wiki Activity
dd40a80102
rust/tests/ui/traits/issue-33140.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

66 lines
2.3 KiB
Plaintext
Raw Normal View History

Don't print full paths in overlap errors
2022-11-10 04:21:11 +00:00
error[E0119]: conflicting implementations of trait `Trait` for type `(dyn Send + Sync + 'static)`
implement a hack to make traitobject 0.1.0 compile
2019-01-03 21:46:46 +00:00
--> $DIR/issue-33140.rs:9:1
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
|
LL | impl Trait for dyn Send + Sync {
| ------------------------------ first implementation here
...
LL | impl Trait for dyn Sync + Send {
Don't print full paths in overlap errors
2022-11-10 04:21:11 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `(dyn Send + Sync + 'static)`
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
Don't print full paths in overlap errors
2022-11-10 04:21:11 +00:00
error[E0119]: conflicting implementations of trait `Trait2` for type `(dyn Send + Sync + 'static)`
implement a hack to make traitobject 0.1.0 compile
2019-01-03 21:46:46 +00:00
--> $DIR/issue-33140.rs:22:1
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
|
LL | impl Trait2 for dyn Send + Sync {
| ------------------------------- first implementation here
...
LL | impl Trait2 for dyn Sync + Send + Sync {
Don't print full paths in overlap errors
2022-11-10 04:21:11 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `(dyn Send + Sync + 'static)`
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
implement a hack to make traitobject 0.1.0 compile
2019-01-03 21:46:46 +00:00
error[E0592]: duplicate definitions with name `abc`
--> $DIR/issue-33140.rs:29:5
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
|
Use smaller def span for functions Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-08-12 21:02:14 +00:00
LL | fn abc() -> bool {
| ^^^^^^^^^^^^^^^^ duplicate definitions for `abc`
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
...
Use smaller def span for functions Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-08-12 21:02:14 +00:00
LL | fn abc() -> bool {
| ---------------- other definition for `abc`
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
Continue compilation even if inherent impl checks fail
2024-02-14 21:04:51 +00:00
error[E0034]: multiple applicable items in scope
--> $DIR/issue-33140.rs:45:40
|
LL | assert_eq!(<Foo<dyn Send + Sync>>::abc(), false);
| ^^^ multiple `abc` found
|
note: candidate #1 is defined in an impl for the type `Foo<(dyn Send + Sync + 'static)>`
--> $DIR/issue-33140.rs:29:5
|
LL | fn abc() -> bool {
| ^^^^^^^^^^^^^^^^
note: candidate #2 is defined in an impl for the type `Foo<(dyn Send + Sync + 'static)>`
--> $DIR/issue-33140.rs:35:5
|
LL | fn abc() -> bool {
| ^^^^^^^^^^^^^^^^
error[E0034]: multiple applicable items in scope
--> $DIR/issue-33140.rs:47:40
|
LL | assert_eq!(<Foo<dyn Sync + Send>>::abc(), true);
| ^^^ multiple `abc` found
|
note: candidate #1 is defined in an impl for the type `Foo<(dyn Send + Sync + 'static)>`
--> $DIR/issue-33140.rs:29:5
|
LL | fn abc() -> bool {
| ^^^^^^^^^^^^^^^^
note: candidate #2 is defined in an impl for the type `Foo<(dyn Send + Sync + 'static)>`
--> $DIR/issue-33140.rs:35:5
|
LL | fn abc() -> bool {
| ^^^^^^^^^^^^^^^^
error: aborting due to 5 previous errors
add coherence future-compat warnings for marker-only trait objects The future-compat warnings break code that assumes that `dyn Send + Sync != dyn Sync + Send`, and are the first step in making them equal. cc #33140. It should be possible to revert this commit when we're done with the warnings.
2018-12-03 21:27:25 +00:00
Continue compilation even if inherent impl checks fail
2024-02-14 21:04:51 +00:00
Some errors have detailed explanations: E0034, E0119, E0592.
For more information about an error, try `rustc --explain E0034`.
Reference in New Issue Copy Permalink