-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Labels
A-type-system
Area: Type system
Comments
Merged
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.
Reproduced with 0252c30 -- nominating for milestone 5, production-ready |
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. |
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
A program like:
yields the error
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 au8
, but it seems to have determined it's ani32
at that point which I thought would have suppressed the first error?The text was updated successfully, but these errors were encountered: