Deprecate and soft-remove error codes

[Mark-Simulacrum]

Today's compiler team meeting seemed to expose rough consensus that error codes as they stand today are not helping end-users fix code, or helping us develop the compiler.

This is because error codes do not meaningfully identify an error to an experienced user, so one cannot derive meaning from them without grepping the compiler codebase (and, sometimes, --explain can help). However, in many cases, a single error code is emitted for multiple similar errors (from a user perspective) but internally the causes of those errors may be quite different. It is also true that many of the complicated Rust errors that users ask for help with are not ones that can be readily explained in the abstract -- looking and helping with specific code is necessary.

It is then our impression that removing the error codes, as detailed below, is a reasonable step to take.

This issue proposes that we deprecate the --explain flag to the compiler and silence emission of error codes in compiler messages. That is, we would no longer emit error[EXXX]: ... instead just emitting error: ..., and no longer print For more information about this error, try "rustc --explain E0282".. We would also stop publishing new versions of the error index.

We would not delete the infrastructure in the compiler that supports this functionality, though, i.e., error code definitions, explanations, error emission would still take E3303 or a similar error as it does today. Furthermore, if -Zui-testing is passed, the error codes would be essentially emitted just as before. This means that reverting the deprecation/removal would be fairly easy. (Notably, we currently rely on these error codes in tidy to check that they're still being emitted by the compiler. Arguably, that's not immediately helpful, but we don't want to break that functionality for no reason if we decide to later revert).

If there are no significant complaints from end users, we may consider removing the functionality completely (i.e., no longer keeping the error code registry and explanations around at all) at a later point in time, but this explicitly does not propose making such a step. It has been noted during discussion of this on Discord that the future of error emission may involve something like #61132 which would somewhat supersede numeric error codes. @eddyb also points out that if we don't go that far, we can at least try to get wins by replacing numeric error codes with alphabetic identifiers, such as error[BorrowCk.UseAfterMove]: ... to allow grouping errors by type and/or potentially emitting no more than one of a particular category of error.

I am filing this issue here, rather than as (for example) a compiler team meeting proposal, because I would like to get some feedback and discussion in an async context, and perhaps even come to a consensus on this plan, without using up a full Friday slot.

cc @rust-lang/wg-diagnostics @GuillaumeGomez

[eddyb]

To be fair, I did mostly refer to #61132 when talking about (alphabetic) "identifiers", but I agree that we can do something along those lines even without #61132.

[nikomatsakis]

I would like feedback from newer users on this point -- it might be that a internals or users thread would help get useful data.

[Mark-Simulacrum]

I will endeavor to make a post to users (I think internals, at least presumably, is not a good venue for finding representative beginners). Maybe a twitter poll or something along those lines makes sense, too, phrased along the lines of "Have you used --explain?" (Since error codes otherwise do not serve a purpose).

[frondeus]

I know few people in my company which were recommending using --explain for beginners. My boss said it is a blessing that --explain gives you more context why error happened and what are common solutions.

But in last year I used it maybe twice.

[fan-tom]

I used error codes a lot when started learning rust, but mostly by error-index than by --explain, epsecially because IntellijIDEA automatiaclly turns them to link and opening error description is as easy as clicking that link.

[estebank]

Just published https://twitter.com/ekuber/status/1203005186228146176 to unofficially get some numbers.

The problem I see is that we do not have any way of tracking usage of --explain, so we don't know whether it is useful, and we can get numbers from the error code index, but it'll be hard to figure out how many of those visitors come due to the error code and how many come there from the error message.

[estebank]

From the description of the conversation (haven't read the meeting transcript yet and I couldn't attend it when it happened) it seems to me that it would be an argument to expand the index with many more specific cases. I do feel that a lot of the shorter descriptions can be subsumed by the diagnostic itself, but there are cases where we can't identify which of a handful of cases we've encountered so we need to describe 3 or 4 different causes for the current problem. For those later cases, the index will always be a useful communication tool.

[skade]

We got active positive feedback at RustBridge Berlin on the errors and their explanations.

[eddyb]

Also, in case this is unclear: we can get the benefits of --explain without error codes, by having a flag to add the explanations after every error and silence duplicate errors etc.

It would likely be more useful than codes, including for IDEs, for the same reason codes are inconvenient for me: they are like a pointer address I have to manually "dereference".

[estebank]

@eddyb the problem I see with that is if we update a diagnostic but somehow forget to update the index, then we loose searchability. Also, error codes rarely change their meaning over time, but the messages can be wildly different as we iterate and improve on things. This means the potential pool of discoverable documentation decreases over time.

The idea you're talking about sounds like --teach to me, but that will require even more boilerplate throughout and increases the threshold for new contributors from "write a new markdown file and add to a list" to "write code with understanding of the DiagnosticBuilder API".

[Ixrec]

Although I'm not a "new user", I very much like the idea of:

replacing numeric error codes with alphabetic identifiers, such as error[BorrowCk.UseAfterMove]: ... to allow grouping errors by type and/or potentially emitting no more than one of a particular category of error.

and would like to add to this that for many errors, there may be multiple things worth explaining, and human-readable identifiers give us a useful way of distinguishing them. For example, if a user runs into a borrow check error involving async/await and closures, I would expect some users need to --explain the basic borrow checking rules, other users need to --explain closure captures, while still others need to only --explain borrowing across yield points. This seems potentially more helpful to users and easier to maintain than writing a single very long error explanation for every specific combination of circumstances that we put a different short error message on, without all the uncertainty and complexity that --teach-like proposals bring.

[jrop]

I rather like the "explain" system (I have used it a few times), although I suppose that an alpha-numeric system may be more ergonomic.