rustc_target: Add pauth-lr aarch64 target feature
Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time.
r? `@Amanieu`
Instead of towards negative infinity as is currently the case.
This done so that the obvious expectations of
`midpoint(a, b) == midpoint(b, a)` and
`midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even
more obvious implementation `(a + b) / 2` true.
https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
Downgrade `untranslatable_diagnostic` and `diagnostic_outside_of_impl` to `allow`
Current implementation of translatable diagnostics infrastructure unfortunately causes some friction for compiler contributors. While we don't have a redesign that causes less friction in place, let's downgrade the internal `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints so we don't indicate to contributors that they *have* to use the current translation infra.
I purposefully left `#[allow(untranslatable_diagnostic)]` and `#[allow(diagnostic_outside_of_impl)]` instances untouched because that seems like unnecessary additional churn.
See <https://github.com/rust-lang/rust/issues/132181> for context.
r? `@davidtwco` (or wg-diagnostics/compiler)
(Big performance change) Do not run lints that cannot emit
Before this change, adding a lint was a difficult matter because it always had some overhead involved. This was because all lints would run, no matter their default level, or if the user had `#![allow]`ed them. This PR changes that. This change would improve both the Rust lint infrastructure and Clippy, but Clippy will see the most benefit, as it has about 900 registered lints (and growing!)
So yeah, with this little patch we filter all lints pre-linting, and remove any lint that is either:
- Manually `#![allow]`ed in the whole crate,
- Allowed in the command line, or
- Not manually enabled with `#[warn]` or similar, and its default level is `Allow`
As some lints **need** to run, this PR also adds **loadbearing lints**. On a lint declaration, you can use the ``@eval_always` = true` marker to label it as loadbearing. A loadbearing lint will never be filtered (it will always run)
Fixes#106983
Deny calls to non-`#[const_trait]` methods in MIR constck
This is a (potentially temporary) fix that closes off the mismatch in assumptions between MIR constck and typeck which does the const traits checking. Before this PR, MIR constck assumed that typeck correctly handled all calls to trait methods in const contexts if effects is enabled. That is not true because typeck only correctly handles callees that are const. For non-const callees (such as methods in a non-const_trait), typeck had never created an error.
45089ec19e/compiler/rustc_hir_typeck/src/callee.rs (L876-L877)
I called this potentially temporary because the const checks could be moved to HIR entirely. Alongside the recent refactor in const stability checks where that component could be placed would need more discussion. (cc ```@compiler-errors``` ```@RalfJung)```
Tests are updated, mainly due to traits not being const in core, so tests that call them correctly error.
This fixes https://github.com/rust-lang/project-const-traits/issues/12.
coverage: Consolidate creation of covmap/covfun records
This code for creating covmap/covfun records during codegen was split across multiple functions and files for dubious historical reasons. Having it all in one place makes it easier to follow.
This PR also includes two semi-related cleanups:
- Getting the codegen context's `coverage_cx` state is made infallible, since it should always exist when running the code paths that need it.
- The value of `covfun_section_name` is saved in the codegen context, since it never changes at runtime, and the code that needs it has access to the context anyway.
---
Background: Coverage instrumentation generates two kinds of metadata that are embedded in the final binary. There is per-CGU information that goes in the `__llvm_covmap` linker section, and per-function information that goes in the `__llvm_covfun` section (except on Windows, where slightly different section names are used).
