Closed cuviper closed 1 year ago
This seems to have improved between 1.48.0 and 1.49.0-beta.5. Now we get:
error[E0283]: type annotations needed
--> src/main.rs:6:27
|
6 | assert!(array.nrows() < u8::MAX.into());
| ^ -------------- this method call resolves to `T`
| |
| cannot infer type
|
= note: cannot satisfy `usize: PartialOrd<_>`
T
comes a bit out of nowhere (the Into
trait declaration) and there could probably be some suggestions or help around how comparisons desugar, but the message is substantially correct.
Current output:
error[E0283]: type annotations needed
--> src/main.rs:6:37
|
6 | assert!(array.nrows() < u8::MAX.into());
| - ^^^^
| |
| type must be known at this point
|
note: multiple `impl`s satisfying `usize: PartialOrd<_>` found
--> src/main.rs:27:5
|
27 | impl PartialOrd<Foo> for usize {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: and another `impl` found in the `core` crate: `impl PartialOrd for usize;`
help: try using a fully qualified path to specify the expected types
|
6 | assert!(array.nrows() < <u8 as Into<T>>::into(u8::MAX));
| ++++++++++++++++++++++ ~
In
num-bigint
master, we've implementedPartialEq
andPartialOrd
between the bigint types and the primitive integers. I'm reconsidering this, because I've experienced a lot of type inference failures from afar, in modules that aren't usingnum-bigint
at all. I'm not too surprised by that, because it really does add ambiguity, but some of the errors are not helpful.Here's a reduced example: playground
AFAICS the "needed for _" and the suggested "explicit type" are identical, and it doesn't change anything if I add that type on
array
anyway (usingndarray::Dim
instead of that private path). Besides,nrows()
always returnsusize
, and "cannot infer type for typeusize
" is nonsense.The last note about
PartialOrd<_>
is the only part that really seems relevant, although I think it could also mention thatu8::MAX.into()
is ambiguous. In this example,usize
implementsPartialOrd<usize>
andPartialOrd<Foo>
, andu8
implements lots ofInto<{integer}>
, though notInto<Foo>
. The compiler could match up the only answer,PartialOrd<usize>
andInto<usize>
, but I guess it's not that aggressive.In the full
num-bigint
case, we would haveu8: Into<BigInt> + Into<BigUint>
too, so then matchingPartialOrd
andInto
really is ambiguous even if the compiler tried harder.Meta
rustc --version --verbose
: