-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Type inference regression on nightly-2024-05-20
#125319
Comments
Regression in #99969. This code used to infer fn main() {
let _: Box<_> = ['a'].into_iter().collect();
} @rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged T-libs-api |
Per #99969 (comment) this is a known breakage, which can be addressed by updating your project's |
Does this mean it will be enabled by 2024 edition? |
It fixes an issue when the crate couldn't be built using nightly due to time dependency. See <rust-lang/rust#125319>.
A type inference regression is permitted breakage according to Rust RFC 1122. This is not even a change in type inference though, it's rather because of type inference. In particular, when we add an impl and that means now 2 possible impls resolve, instead of 1, it can break things. Customarily, if the library teams expect a breakage may be particularly widespread, rejecting it is discussed and there is a formal decision to accept it or not. However it's not clear to me from the FCP's comments (or lack thereof) if T-libs-api discussed this breakage before/during the FCP, beyond the chatter that occurred there? #99969 (comment) @rust-lang/libs-api Can I just assume that if T-libs-api FCPs a new impl of something like From or FromIterator, and then a team member r+'s landing something that they said "maybe a crater run" about, that you have discussed the breakage possibility and said "worth it"? It may be helpful if you just formally note "probably will break someone relying on a particularly strained Spicy option: r+ it the moment it hits the final comment period so we might actually get any such reports in the 10 day period. |
Signed-off-by: Sergey "Shnatsel" Davidoff <shnatsel@gmail.com>
It fixes an issue when the crate couldn't be built using nightly due to time dependency. See <rust-lang/rust#125319>.
[beta-1.79] fix(toml): Don't warn on lints.rust.unexpected_cfgs.check-cfg Beta backports: - #13913 (sort of): removes just the lint warning (in a different way to be minimal) so we reduce warning noise for people using this key on nightly In order to make CI pass, the following PRs are also cherry-picked: - #13865 - #13834 (only `time` due to rust-lang/rust#125319) - #13901 - #13931 - #13920 - #13890 - disable link check (not a cherry pick)
Previously shadow wouldn't compile on nightly due to a rust type inference change that breaks older rust code, and they intend to stabilize this change. For us that breakage occurs in the time crate, so this PR upgrades all dependencies (including the time library) to fix the build errors. rust-lang/rust#99969 (comment) rust-lang/rust#125319
Previously shadow wouldn't compile on nightly due to a rust type inference change that breaks existing rust code, and they intend to stabilize this change. For us that breakage occurs in the time crate, so this PR upgrades all dependencies (including the time library) to fix the build errors. rust-lang/rust#99969 (comment) rust-lang/rust#125319
We discussed this regression in today's libs-api team meeting, and are inclined not to revert. 1.80 is in beta already so we'll start seeing fallout in the beta crater runs. The team will re-evaluate if the beta crater runs look disastrous with many crates other than |
## Problem `cargo +nightly check` fails ## Summary of changes Updates `measured`, `time`, and `crc32c`. * `measured`: updated to fix rust-lang/rust#125763. * `time`: updated to fix rust-lang/rust#125319 * `crc32c`: updated to remove some nightly feature detection with a removed nightly feature
## Problem `cargo +nightly check` fails ## Summary of changes Updates `measured`, `time`, and `crc32c`. * `measured`: updated to fix rust-lang/rust#125763. * `time`: updated to fix rust-lang/rust#125319 * `crc32c`: updated to remove some nightly feature detection with a removed nightly feature
By setting time 0.3.36 as minimally required version in accordance to rust-lang/rust#125319 (comment)
# Background Recert uses the `simple_asn1` crate in order to calculate the SKID on RSA keys # Problem The `simple_asn1` crate depends on the `time` crate, which recently encountered a regression [1] due to [2] that caused the `simple_asn1` crate to fail to compile with our locked version (0.3.30) of the `time` crate. # Solution Updated the `time` crate to version 0.3.36, which contains a fix for the regression. Re-ran vendoring. [1] time-rs/time#681 [2] rust-lang/rust#125319
`rustc --version`: `v1.80.0` has a type inference regression. This causes compilation of `centerpiece` to fail, because we use an affected version of the `time` crate. This updates the time crate to a released version with a fix. Reference: - NixOS/nixpkgs#332957 - rust-lang/rust#125319 - rust-lang/rust#99969
`rustc --version`: `v1.80.0` has a type inference regression. This causes compilation of `centerpiece` to fail, because we use an affected version of the `time` crate. This updates the time crate to a released version with a fix. Reference: - NixOS/nixpkgs#332957 - rust-lang/rust#125319 - rust-lang/rust#99969
Code
I tried this code:
I expected to see this happen: Compile successfully.
Instead, this happened: Compilation failed with the following.
Version it worked on
It most recently worked on:
rustc --version --verbose
:Version with regression
rustc --version --verbose
:@rustbot modify labels: +regression-from-stable-to-nightly-regression-untriaged
The text was updated successfully, but these errors were encountered: