-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
patterns: wrong tracking issue? #123643
Comments
What do you mean? Why would this beta a beta-to-stable regression? It regressed with #107606. |
cc @oli-obk pattern types need a real tracking issue, and you need to delay a span bug here rather than ICE |
right now: beta -> nightly regression |
yes? but you can say that about every single regression that ever gets filed lol |
exactly, unless it gets fixed in time :) |
I don't see the purpose of pointing out that this is a potential beta regression before it has even landed on nightly, unless there's some reason that this is particularly difficult to fix, particularly affects user-facing code, or we expect it to slip the beta promotion for some reason. |
Well, there are a few cases where feature gates actually do work and prevent crashes on stable 🙃 |
maybe internal features should just hard abort compilation if they aren't set |
might also solve some of the internal-feature ices we are getting from time to time |
...I do not see how it would be a regression, because we can safely bet on no one requiring the The code did not travel back in time to 1.77 compilers and suddenly become usable stable API. |
its a regression because the compiler now crashes/ICEs where it would previously just show an error message. |
please show me the codebase that regressed. |
code that was not committed until April 8th, thus incapable of regressing on stable, yes. |
ah yes not yet. this is why I wrote |
If it arrived on 1.79 on stable, it would be code that, since the moment it has been useful to write, has always ICEd. 1.79 cannot retrocausally regress code, unless you have a TARDIS or somesuch. |
I it was code that did not ICE on 1.78, and now ICEs on 1.79, so that makes it a regression. |
It was code that did not exist in this world on 1.78. It didn't exist in some timeless platonic realm of Forms. No actual programs were harmed in the making of this music video. |
I suppose if you insist we can call them "regressions" when they involve code samples that just came into being, but I wish to know what I should call it when my actual tests fail from version to version of rustc and I have to spend hours bisecting the issue and figuring out where in the codebase it has gone wrong and fixing the problem before the new version comes out, either in the code or in rustc. Because it sure isn't a just-fabricated problem with just-fabricated code, it's something that matters in code that is supposed to build and work on the latest stable Rust version. |
What it is is a feature gated feature ICEing without the feature gate, so we would see it ICE on stable if untreated. This means it is a higher priority ICE than an ICE that is only reachable with feature gates. We have not used "regression" as a term for "error -> ICE" changes, as by definition that'a true for any ICE that does not require feature gates. If we flagged it as a regression, that would flood and taint the actually problematic regressions. We do flag these as regressions if there is no error before the ICE, as the user then has no information on how to fix it. So while @matthiaskrgr is technically correct, in practice we don't and shouldn't use this terminology |
Rollup merge of rust-lang#123648 - oli-obk:pattern_types_syntax, r=compiler-errors Avoid ICEing without the pattern_types feature gate fixes rust-lang#123643
While checkout out this ice (which does not require a feature gate btw, so potential beta-to-stable regression, which is inconvenient
snippet:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustc
Program output
I clicked the tracking issue from
= note: see issue #54882 #54882 for more information
= help: add
#![feature(pattern_types)]
to the crate attributes to enable= note: this compiler was built on 2024-04-08; consider upgrading it if it is out of date
which is about an
optimize
attribute and does not mention patterns or links to a related PR at all? 🤔The text was updated successfully, but these errors were encountered: