rust/compiler/rustc_codegen_llvm/src/errors.rs, branch 1.80.0

Use an error struct instead of a panic

2024-05-15T09:14:45+00:00

Rename `IntoDiagnostic` as `Diagnostic`.

2024-03-10T22:15:09+00:00

To match `derive(Diagnostic)`. Also rename `into_diagnostic` as `into_diag`.

Rename `DiagnosticBuilder` as `Diag`.

2024-02-27T21:55:35+00:00

Much better! Note that this involves renaming (and updating the value of) `DIAGNOSTIC_BUILDER` in clippy.

Overhaul `Diagnostic` args.

2024-02-22T01:51:05+00:00

First, introduce a typedef `DiagnosticArgMap`. Second, make the `args` field public, and remove the `args` getter and `replace_args` setter. These were necessary previously because the getter had a `#[allow(rustc::potential_query_instability)]` attribute, but that was removed in #120931 when the args were changed from `FxHashMap` to `FxIndexMap`. (All the other `Diagnostic` fields are public.)

errors: only eagerly translate subdiagnostics

2024-02-15T10:34:41+00:00

Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). Signed-off-by: David Wood

Rollup merge of #120631 - saethlin:invalid-target-ice, r=compiler-errors

2024-02-06T18:40:08+00:00

Emit a diagnostic for invalid target options This turns the ICE in https://github.com/rust-lang/rust/issues/120625 into a translatable diagnostic.

Emit a diagnostic for invalid target options

2024-02-04T03:03:25+00:00

`Diagnostic` cleanups

2024-02-02T22:02:50+00:00

- `emitted_at` isn't used outside the crate. - `code` and `messages` are public fields, so there's no point have trivial getters/setters for them. - `suggestions` is public, so the comment about "functionality on `Diagnostic`" isn't needed.

llvm: simplify data layout check

2024-01-18T10:46:03+00:00

Don't skip the inconsistent data layout check for custom LLVMs. With #118708, all targets will have a simple test that would trigger this check if LLVM's data layouts do change - so data layouts would be corrected during the LLVM upgrade. Therefore, with builtin targets, this check won't trigger with our LLVM because each target will have been confirmed to work. With non-builtin targets, this check is probably useful to have because you can change the data layout in your target and if its wrong then that could lead to bugs. When using a custom LLVM, the same justification makes sense for non-builtin targets as with our LLVM, the user can update their target to match their LLVM and that's probably a good thing to do. However, with a custom LLVM, the user cannot change the builtin target data layouts if they don't match - though given that the compiler's data layout is used for layout computation and a bunch of other things - you could get some bugs because of the mismatch and probably want to know about that. `CFG_LLVM_ROOT` was also always set during local development with `download-ci-llvm` so this bug would never trigger locally. Signed-off-by: David Wood

Rename consuming chaining methods on `DiagnosticBuilder`.

2024-01-09T20:40:00+00:00

In #119606 I added them and used a `_mv` suffix, but that wasn't great. A `with_` prefix has three different existing uses. - Constructors, e.g. `Vec::with_capacity`. - Wrappers that provide an environment to execute some code, e.g. `with_session_globals`. - Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`. The third case is exactly what we want, so this commit changes `DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`. Thanks to @compiler-errors for the suggestion.