Change:
<ins> //! This test ensures we do not ICE for unimplemented //! patterns unless the feature gate is enabled. #![feature(core_pattern_type)] #![feature(core_pattern_types)] use std::pat::pattern_type; type Always = pattern_type!(Option<u32> is Some(_)); //~^ ERROR: pattern types are unstable type Binding = pattern_type!(Option<u32> is x); //~^ ERROR: pattern types are unstable fn main() {} </ins>

Discussion:
While checkout out this ice (which does not require a feature gate btw, so potential beta-to-stable regression, which is inconvenient <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unsupported pattern for pattern type: Pat {', 'error: internal compiler error: unsupported pattern for pattern type: Pat {' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeof] expanding type alias [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --I clicked the tracking issue from = note: see issue more information = help: add 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 attribute and does not mention patterns or links to a related PR at all? :thinking:
What do you mean? Why would this beta a beta-to-stable regression? It regressed with .
cc pattern types need a real tracking issue, and you need to delay a span bug here rather than ICE
right now: beta -nightly regression once nightly gets promoted to beta: stable -beta regression once beta gets promoted to stable: stable -stable 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 macro before the feature's library API landed. 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 is technically correct, in practice we don't and shouldn't use this terminology