ErrorID no longer being reported for 54

[ckipp01]

Compiler version

3.2.2-RC1-bin-20220930-fff8c0d-NIGHTLY-git-fff8c0d

Minimized code

@main def ParameterizedTypeLacksArgumentsID =
  trait Foo(x: Int)
  val foo = new Foo {}

Output

Previously this code would error with the unique error id of 54. You can see the expected output here. Now this is reported without an error ID.

Expectation

I'd expect the error ID to still be reported here. I consider it a regression that it's not.

Digging in, it seems that this was removed in #15986.

[dwijnand]

It now emits "missing argument for parameter x of constructor Foo in trait Foo: (x: Int): Foo", which is a string (in Applications) which gets converted into a message with Message.toNoExplanation, which I think is a migration assistant. But to preserve the original error message we need to catch this earlier, for this specific error case.

[odersky]

The problem here is that our error messages are not in a state where we want to freeze them. If we want to have really good error messages we need the liberty to change them and refactor them freely. That means cannot assume that error ids will be stable by any means.

[ckipp01]

The problem here is that our error messages are not in a state where we want to freeze them

The general problem with this is sort of a catch 22 then. Because for tooling, this matters a lot. Without out, we have to rely on ugly things like regexing diagnostics, which are also subject to change. I don't fully understand why an error can't have a stable id yet. It's kind of embarrassing that years after the release this still isn't the case.

I seemingly got overwhelming support in #14904, but I continually see your messages as against this. So where does this leave us? Do I just freeze on that effort, which already has significant effort in it, or are we able to try and force some sort of stabilization? I have an inkling that your average user cares more about stable and helpful diagnostics than cool new language or syntax features.

[odersky]

The problem is not error message numbers. It's that we need to provide more insight into what goes wrong. Sometimes that necessitates refactorings in the compiler itself, which will make the compiler hit different paths producing different errors. That's inevitable. The alternative is total stagnation where no improvements are made and no bugs get fixed.

In this case the error message number was dropped because the new path of the compiler goes to a point where errors are still produced as strings. That happens a lot in the compiler. We can try to reduce that by adding (a lot) more cases to messages.scala. I believe in the long term this will happen.

So to summarize: We can (over time) reduce the situations where no error message number is given. We cannot guarantee that error message ids will be stable over any period of time, in the sense that an erroneous program might well fail with different (hopefully more helpful) messages in newer releases.

[SethTisue]

We cannot guarantee that error message ids will be stable over any period of time, in the sense that an erroneous program might well fail with different (hopefully more helpful) messages in newer releases

Sounds okay to me. Perhaps we can all agree (or at least accept) that the “stable” part of this is a nice-to-have rather than some kind of commitment or hard constraint.

I don't see the word “stable” over at #14904 .