mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
14b96659e4
rust/src/test/ui/did_you_mean/issue-42764.stderr

28 lines
1.0 KiB
Plaintext
Raw Normal View History

suggest one-argument enum variant to fix type mismatch when applicable Most notably, this will suggest `Some(x)` when the expected type was an Option<T> but we got an x: T. Resolves #42764.
2017-07-11 22:03:58 -05:00
error[E0308]: mismatched types
--> $DIR/issue-42764.rs:21:43
|
Update UI tests
2018-02-22 18:42:32 -06:00
LL | this_function_expects_a_double_option(n);
suggest one-argument enum variant to fix type mismatch when applicable Most notably, this will suggest `Some(x)` when the expected type was an Option<T> but we got an x: T. Resolves #42764.
2017-07-11 22:03:58 -05:00
| ^ expected enum `DoubleOption`, found usize
|
= note: expected type `DoubleOption<_>`
found type `usize`
Adjust new suggestions to the suggestion guidelines
2017-07-21 06:59:17 -05:00
help: try using a variant of the expected type
suggest one-argument enum variant to fix type mismatch when applicable Most notably, this will suggest `Some(x)` when the expected type was an Option<T> but we got an x: T. Resolves #42764.
2017-07-11 22:03:58 -05:00
|
Update UI tests
2018-02-24 17:01:39 -06:00
LL | this_function_expects_a_double_option(DoubleOption::FirstSome(n));
path, not name, in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to, like, actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing, but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case, we excise the prelude path, preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2, v3, &c.: we trust our successors to grep—excuse me, ripgrep—for that.) Also, don't make this preëmpt the existing probe-for-return-type suggestions, despite their being looked unfavorably upon, at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.
2017-07-15 12:26:11 -05:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
Update UI tests
2018-02-24 17:01:39 -06:00
LL | this_function_expects_a_double_option(DoubleOption::AlternativeSome(n));
path, not name, in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to, like, actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing, but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case, we excise the prelude path, preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2, v3, &c.: we trust our successors to grep—excuse me, ripgrep—for that.) Also, don't make this preëmpt the existing probe-for-return-type suggestions, despite their being looked unfavorably upon, at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.
2017-07-15 12:26:11 -05:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
suggest one-argument enum variant to fix type mismatch when applicable Most notably, this will suggest `Some(x)` when the expected type was an Option<T> but we got an x: T. Resolves #42764.
2017-07-11 22:03:58 -05:00
only issue "variant of the expected type" suggestion for enums Felix S. Klock II pointed out that this suggestion (introduced in pull-request #43178 / eac74104) was being issued for one-field-struct expected types (in which case it is misleading and outright wrong), even though it was only intended for one-field enum-variants (most notably, `Some`). Particularly tender-hearted code-historians may be inclined to show mercy towards the author of #43178 on the grounds that it's somewhat confusing that struct field definitions are given in a type called `ty::VariantDef`. Add a conditional to adhere to the original intent. (It would be possible to generalize to structs, but not obviously net desirable.) This adds a level of indentation, so the diff here is going to be easier to read in ignore-whitespace mode (`-w`). Resolves #55250.
2018-10-21 17:37:01 -05:00
error[E0308]: mismatched types
--> $DIR/issue-42764.rs:37:33
|
LL | let _c = Context { wrapper: Payload{} };
| ^^^^^^^^^ expected struct `Wrapper`, found struct `Payload`
|
= note: expected type `Wrapper`
found type `Payload`
error: aborting due to 2 previous errors
suggest one-argument enum variant to fix type mismatch when applicable Most notably, this will suggest `Some(x)` when the expected type was an Option<T> but we got an x: T. Resolves #42764.
2017-07-11 22:03:58 -05:00
update tests
2018-03-03 08:59:40 -06:00
For more information about this error, try `rustc --explain E0308`.
Reference in New Issue Copy Permalink