Hi @WG-diagnostics @GuillaumeGomez . Let's talk about replacing numeric error codes with string names. This happens in #67086. Please pick a time at https://terminplaner4.dfn.de/KlpwSW4AuBoCofUS I'll leave a more detailed explanation of the things to discuss below
Done! Also: it's very likely I won't be around on zulip so don't hesitate to ping me on discord.
error_id!(some_name)would alleviate this concern?
no, no, I'm totally on board with nice names
I am opposed to
E0303 where the first is actually restricted to that tight format
right, but we need some intermediate step before moving to full names
otherwise we'll never get it merged
if we did
error_id!(E0303) this would still work as the macro could take an
yes, I think
error_id! macro is a good idea
(makes the lint checking easier too)
I am fine with moving to "E0303" as an intermediate step (to be "quickly" replaced)
so basically all the use sites at macro call sites that were changed from
E0303 could in fact stay as they are and internally call
error_id! on the value, and all the non-macro call sites could just use
yep, and (in theory) we can also make the macro accept either
i.e. internally we map
this_is_a_nice_name to E0303 for now
(or vice versa)
or, as another straw man, we make the macro accept symbols (i.e.,
and then intern the current ids
that way it's all the same type and so forth and super easy to migrate to any string
ah not sure if we have symbols available in
yea doesn't look like it
sure we do?
depends on librustc_span
which has sym (used to by syntax_pos)
ah so it does
Do we have a proposal on the format for the new codes?
nope, I would have assumed "like lints"
My main concerns are that by having a string code that might prove suboptimal we can't really change it afterwards, that the output will be less consistent (ie where do I look for the start of the message) that there's duplication between the message and the code. I feel that it'd be a bigger benefit to try and get --teach working everywhere than try and improve the "error code as non-semantic pointer to docs" problem
But I acknowledge that none of these are big issues
We might have problems dealing with I line docs for a while though
I feel no general pressure to do these changes now rather than later, so if you think there's some benefit to delaying, let's do that
I don't think
sym::the_code is a good idea
It forces recompilation of
rustc_span if you want to add a new error code
which is basically recompiling the whole compiler
error_id!.. we already have
rustc_errors... what's the difference beyond
er, yeah, error_code would be the macro used I guess
(as a side note, I just did goto definition on a proc macro and it worked with RLA and I am speechless)
regardless, I think the issue of recompiling everything when adding a new symbol are not too interesting, i.e, we can make it work (there's no actual reason all symbols need to be in the same place, for example)
just the macro today requires that
but I think that should be fixed first though
but it could be pretty easily written I think to not need that, we'd need some constants that we update (offsets, basically); but it would only need to be updated every so often - we could give ourselves some "margin" so to speak
we shouldn't regress dev UX in the interim
my understanding is that we add error codes like very rarely
I mostly don't add error codes cause I just avoid error codes
but I fairly frequently do add new errors
in any case, if we truly want to prevent typos, the way to do it is a global list
(and compiler or tidy-checking afterwards)
I think my idealized version would be something like this:
category::error_namebased errors. You do not have to register these codes in e.g. a crate that
rustc_parserdepends upon. For example:
That is, descriptions would not be part of the
I don't personally see cause for the latter (it can be in a crate that is a dependency of say, rustc_driver or even
rustc the binary crate).
The first, though, seems to match what I'm thinking with symbols
Although it is worth noting that an advantage of error codes is that they are short, which makes them stick out less in typical error messages, whereas
syntax::missing_comma is not short.
I think that's in practice something we could fix separately
e.g. Cargo could learn to not show error codes
(well, Cargo could learn to tell rustc to not show error codes)
I still feel like for 99% of errors they're not useful
(e.g., I have no idea how we can elaborate on missing comma :)
fwiw, missing comma is a fairly simple error
there are much more complicated ones in terms of understanding
(looking at you, async-await errors...)
I don't personally see cause for the latter (it can be in a crate that is a dependency of say, rustc_driver or even rustc the binary crate).
That's the current state;
rustc_error_codes is only a dep of
But moving them to dynamically loaded "text files" would be even later "linking"
My point is that in most cases we don't need an error code (so adding it can be costly from compiletime perspective) and when we do, it can be long, because you're (more) likely to look at it.
such that you can swap out descriptions at runtime
I am against text files that we load at runtime in rustc, though not the idea in general. If we do that, we might as well just not include them in rustc and have a error code index (HTML/Markdown) like we do today, nixing
Haven't we been hearing that error codes are commonly useful?
We have heard that error codes are useful, yes, but that's not the assertion I'm making
I don't understand the difference in the distinction
I'm saying most errors probably don't benefit from one. Those that do, are harder to fix -- i.e., you need to look at the error for a bit -- so having eye travel across a longer error code isn't a problem.
Hmm; I don't feel confident in making a statistical judgement like that
Remember, we are biased "language experts"
hm, I don't really see that being related, in the sense that all I'm saying is that
error[a very long code that is quite long]: foo isn't great, yes
but it's also true that such errors are ones you look at for a while anyway
but okay, let's presume I'm wrong
I am against text files that we load at runtime in rustc, though not the idea in general. If we do that, we might as well just not include them in rustc and have a error code index (HTML/Markdown) like we do today, nixing rustc --explain.
Can you elaborate on why? It seems to me that error descriptions are only ever needed when there's an error, which is a slow path, so perf shouldn't be an issue. Also, what's the plan for internationalization otherwise (maybe there isn't one?)
Seems we both agree that we need to keep error code length under wraps or they start losing their value :slight_smile:
There is no known plan for internationalization, to my knowledge. I think using it as an argument is odd, it's too far out, and there's no known plan.
It's not about slowness. It's about the fact that "many files on disk" fits poorly with (for example) distros
Finding a naming scheme that achieves that is a tough nut though
I would be interested in hearing from @Manish Goregaokar re. descriptions and translation
What if we move the error code to a note?
then it can be a link, even
or at least length is no longer an issue
@simulacrum hmm, can you try a sample error from today and adjust it?
you mean like paste an example of how it looks?
and how you would change it with your "move to a note"
error[E0502]: cannot borrow `x` as immutable because it is also borrowed as mutable --> src/main.rs:4:13 | 3 | let a = &mut x; | ------ mutable borrow occurs here 4 | let b = &x; | ^^ immutable borrow occurs here 5 | *a = 3; | ------ mutable borrow later used here
error[borrow_check::double_mutable]: cannot borrow `x` as immutable because it is also borrowed as mutable --> src/main.rs:4:13 | 3 | let a = &mut x; | ------ mutable borrow occurs here 4 | let b = &x; | ^^ immutable borrow occurs here 5 | *a = 3; | ------ mutable borrow later used here
error: cannot borrow `x` as immutable because it is also borrowed as mutable --> src/main.rs:4:13 | 3 | let a = &mut x; | ------ mutable borrow occurs here 4 | let b = &x; | ^^ immutable borrow occurs here 5 | *a = 3; | ------ mutable borrow later used here help: longer explanation can be viewed via `rustc --explain borrow_check::double_mutable`
error[borrow_check::double_mutable]: could probably be
last one looks good though
help: use `rustc --explain borrow_check::double_mutable` for a longer explanation help: longer explanation can be viewed via `rustc --explain borrow_check::double_mutable`
yeah, the last one is my option for 'here is how we avoid all problems with length' basically
(and get the advantage that it's easier to drop/edit/etc, in theory)
too bad we can't hyperlink terminal texts lol
such an outdated medium :D
hm, well, we can, I think
or at least on some platforms
but rustc should probably not be doing that
So I like your third snippet; I think that's what we should do
:thumbs_up: from me fwiw
that seems like a move we can do fairly independently
though it will need:
we can do 1. first and separately
@simulacrum @centril there is definitely a plan for internationalization :)
When the code is constant-length its easy to skim past it when its not relevant to you
long names will invariably be… variable
So if I understood correctly, we'll go for string representation as an intermediate step. Then I'll finish my PR.
So I just decided to try to take up this PR, should I hold off on working on it until this change is made (or decided to be not made)? https://github.com/rust-lang/rust/issues/44710#issuecomment-588453311
I would also be willing to help with the transition if you need it
I think we're not yet ready to move of numeric error codes
My comment is totally outdated now too...
Alright, I will go ahead with work on that issue then