Skip to content

Integer type inference confusion #5462

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

Closed
alexcrichton opened this issue Mar 21, 2013 · 2 comments
Closed

Integer type inference confusion #5462

alexcrichton opened this issue Mar 21, 2013 · 2 comments
Labels
A-type-system Area: Type system

Comments

@alexcrichton
Copy link
Member

A program like:

fn foo(_: u8) {}

fn main() {
  let a = 1;
  foo(a.to_u8());
  foo(a);
}

yields the error

$ rustc foo.rs
foo.rs:5:6: 5:16 error: multiple applicable methods in scope
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #1 is `core::i32::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #2 is `core::i8::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #3 is `core::i16::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #4 is `core::u64::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #5 is `core::u16::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #6 is `core::uint::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #7 is `core::int::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #8 is `core::u32::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #9 is `core::u8::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:5:6: 5:16 note: candidate #10 is `core::i64::__extensions__::to_u8`
foo.rs:5   foo(a.to_u8());
               ^~~~~~~~~~
foo.rs:6:6: 6:7 error: mismatched types: expected `u8` but found `i32` (expected u8 but found i32)
foo.rs:6   foo(a);
               ^
error: aborting due to 2 previous errors

I'm not really sure what's quite going on here. The first function invocation looks like it doesn't know what type a is, so it could be anything.

The second invocation I thought would force the compiler to infer that a is a u8, but it seems to have determined it's an i32 at that point which I thought would have suppressed the first error?

bors added a commit that referenced this issue Mar 22, 2013
This is a minor step towards #3571, although I'm sure there's still more work to be done. Previously, `fmt!` collected a bunch of strings in a vector and then called `str::concat`. This changes the behavior by maintaining only one buffer and appending directly into that buffer. This avoids doubly-allocating memory, and it has the added bonus of reducing some allocations in `core::unstable::extfmt`

One of the unfortunate side effects of this is that the `rt` module in `extfmt.rs` had to be duplicated to avoid `stage0` errors. Dealing with the change in conversion functions may require a bit of a dance when a snapshot happens, but I think it's doable.

If the second speedup commit isn't deemed necessary, I got about a 15% speedup with just the first patch which doesn't require any modification of `extfmt.rs`, so no snapshot weirdness.

Here's some other things I ran into when looking at `fmt!`:
* I don't think that #2249 is relevant any more except for maybe removing one of `%i` or `%d`
* I'm not sure what was in mind for using traits with #3571, but I thought that formatters like `%u` could invoke the `to_uint()` method on the `NumCast` trait, but I ran into some problems like those in #5462

I'm having trouble thinking of other wins for `fmt!`, but if there's some suggestions I'd be more than willing to look into if they'd work out or not.
@catamorphism
Copy link
Contributor

Reproduced with 0252c30 -- nominating for milestone 5, production-ready

@graydon
Copy link
Contributor

graydon commented May 23, 2013

closing INVALID, this is actually correct behavior; using method-presence to pick integer types winds up randomly causing truncation, we used to do this and stopped.

@graydon graydon closed this as completed May 23, 2013
oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
…g, r=flip1995

fix redundant_pattern_matching lint

- now it handles `while let` case  (related to rust-lang#5462)
- better suggestions in `if let` case

changelog: Fix suggestion in `redundant_pattern_matching` and also apply this lint to the `while let` case
joeri pushed a commit to joeri/circular that referenced this issue Sep 27, 2022
According to Clippy and the Rust issue tracker[0] you should use the vec!
macro when initializing a vector to 0 bytes.

[0] rust-lang/rust#5462
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

3 participants