search

Rust-GCC / gccrs

GCC Front-End for Rust
https://rust-gcc.github.io/
GNU General Public License v2.0
2.4k stars 155 forks source link

Better distinguish between user-level errors and internal (consistency etc.) checks #1634

Open tschwinge opened 1 year ago

tschwinge commented 1 year ago

I thought we had an issue open for that already, but I can't find any.

We already discussed this a year ago, https://hackmd.io/GhC6flQqQNOYzzz3Vq7ufg#Better-distinguish-between-user-level-errors-and-internal-consistency-etc-checks "GCC Rust Meeting 2021-11-05":

Better distinguish between user-level errors and internal (consistency etc.) checks.

Use rust_error_at etc. for the former (and test cases!), and rust_assert/rust_internal_error for the latter. This will help cleanup the code over time to distingush internal errors vs program errors.

This has now come up again in review of https://inbox.sourceware.org/gcc-patches/CAFiYyc0epcVg7B+xq_hac7TUgO8eBJAWM4d6+ZFo1QZrCYidEQ@mail.gmail.com "[PATCH Rust front-end v3 15/46] gccrs: Add expansion pass for the Rust front-end" by @rguenth:

[...] I wondered whether rust_error_at are user-facing diagnostics or internal errors?

rguenth commented 1 year ago

It's also important for translators who can spend their time on user-facing errors.

CohenArthur commented 1 year ago

Right. This should already be the case in most of the codebase, but there are some stray calls to rust_error_at() left, which I'll remove. Especially in more modern additions, we have used rust_assert and rust_error_at properly instead of interchangeably. I'll take a look at all uses of rust_error_at and make sure they are justified