patterns: wrong tracking issue? about rust

[oli-obk]

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

[matthiaskrgr]

exactly, unless it gets fixed in time :)

[oli-obk]

maybe internal features should just hard abort compilation if they aren't set

[compiler-errors]

While checkout out this ice (which does not require a feature gate btw, so potential beta-to-stable regression, which is inconvenient

What do you mean? Why would this beta a beta-to-stable regression? It regressed with #107606.

[compiler-errors]

cc @oli-obk pattern types need a real tracking issue, and you need to delay a span bug here rather than ICE

[matthiaskrgr]

right now: beta -> nightly regression
once nightly gets promoted to beta: stable -> beta regression
once beta gets promoted to stable: stable -> stable regression?

[compiler-errors]

yes? but you can say that about every single regression that ever gets filed lol

[compiler-errors]

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.

[matthiaskrgr]

Well, there are a few cases where feature gates actually do work and prevent crashes on stable 🙃

[matthiaskrgr]

might also solve some of the internal-feature ices we are getting from time to time

[workingjubilee]

...I do not see how it would be a regression, because we can safely bet on no one requiring the pattern_type! 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.

[matthiaskrgr]

its a regression because the compiler now crashes/ICEs where it would previously just show an error message.

[workingjubilee]

please show me the codebase that regressed.

[matthiaskrgr]

#123643 (comment)

[workingjubilee]

code that was not committed until April 8th, thus incapable of regressing on stable, yes.

[matthiaskrgr]

ah yes not yet. this is why I wrote so potential beta-to-stable regression, which is inconvenient ;)

[workingjubilee]

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.

[matthiaskrgr]

I it was code that did not ICE on 1.78, and now ICEs on 1.79, so that makes it a regression.

[workingjubilee]

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.

[workingjubilee]

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.