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

Use translatable diagnostics in `rustc_const_eval`

2023-06-01T14:45:18+00:00

Rollup merge of #111203 - Kobzol:remark-print-kind, r=tmiasko

2023-05-06T21:32:02+00:00

Output LLVM optimization remark kind in `-Cremark` output Since https://github.com/rust-lang/rust/pull/90833, the optimization remark kind has not been printed. Therefore it wasn't possible to easily determine from the log (in a programmatic way) which remark kind was produced. I think that the most interesting remarks are the missed ones, which can lead users to some code optimization. Maybe we could also change the format closer to the "old" one: ``` note: optimization remark for tailcallelim at /checkout/src/libcore/num/mod.rs:1:0: marked this call a tail call candidate ``` I wanted to programatically parse the remarks so that they could work e.g. with https://github.com/OfekShilon/optview2. However, now that I think about it, probably the proper solution is to tell rustc to output them to YAML and then use the YAML as input for the opt remark visualization tools. The flag for enabling this does not seem to work though (https://github.com/rust-lang/rust/issues/96705#issuecomment-1117632322). Still I think that it's good to output the remark kind anyway, it's an important piece of information. r? ```@tmiasko```

Output LLVM optimization remark kind in `-Cremark` output

2023-05-04T13:39:21+00:00

Stablize raw-dylib, link_ordinal and -Cdlltool

2023-04-18T18:01:07+00:00

errors: generate typed identifiers in each crate

2023-02-22T09:15:53+00:00

Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter. Signed-off-by: David Wood

session: diagnostic migration lint on more fns

2023-01-30T17:11:35+00:00

Apply the diagnostic migration lint to more functions on `Session`. Signed-off-by: David Wood

Remove backwards compat for LLVM 12 coverage format

2023-01-09T15:31:24+00:00

Auto merge of #105421 - jacobbramley:jb/branch-prot-check, r=nagisa

2022-12-17T12:10:27+00:00

Check AArch64 branch-protection earlier in the pipeline. As suggested in #93516. r? `@nagisa`

Check AArch64 branch-protection earlier in the pipeline.

2022-12-06T15:51:57+00:00

As suggested in #93516.

Move linkage type check to HIR analysis and fix semantics issues.

2022-12-05T23:05:43+00:00

This ensures that the error is printed even for unused variables, as well as unifying the handling between the LLVM and GCC backends. This also fixes unusual behavior around exported Rust-defined variables with linkage attributes. With the previous behavior, it appears to be impossible to define such a variable such that it can actually be imported and used by another crate. This is because on the importing side, the variable is required to be a pointer, but on the exporting side, the type checker rejects static variables of pointer type because they do not implement `Sync`. Even if it were possible to import such a type, it appears that code generation on the importing side would add an unexpected additional level of pointer indirection, which would break type safety. This highlighted that the semantics of linkage on Rust-defined variables is different to linkage on foreign items. As such, we now model the difference with two different codegen attributes: linkage for Rust-defined variables, and import_linkage for foreign items. This change gives semantics to the test src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was previously expected to fail to compile. Therefore, convert it into a test that is expected to successfully compile. The update to the GCC backend is speculative and untested.