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

[tschwinge]

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]

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

[CohenArthur]

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