…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#128425 (Make `missing_fragment_specifier` an unconditional error)
 - rust-lang#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features)
 - rust-lang#140770 (add `extern "custom"` functions)
 - rust-lang#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches)
 - rust-lang#142248 (Add supported asm types for LoongArch32)
 - rust-lang#142267 (assert more in release in `rustc_ast_lowering`)
 - rust-lang#142274 (Update the stdarch submodule)
 - rust-lang#142276 (Update dependencies in `library/Cargo.lock`)
 - rust-lang#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library)

Failed merges:

 - rust-lang#140920 (Extract some shared code from codegen backend target feature handling)

r? `@ghost`
`@rustbot` modify labels: rollup

try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various

…n, r=nnethercote,WaffleLapkin

Extract some shared code from codegen backend target feature handling

There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`.

The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. `@GuillaumeGomez` `@antoyo` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features`  does not? The second commit also cleans up a bunch of unneeded complexity added in rust-lang#135927.

The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes:
- Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes rust-lang#134792.
- The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that...
- Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway.

The fourth commit increases consistency of the GCC backend with the LLVM backend.

The last commit does some further cleanup:
- Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes rust-lang#142412.
- Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this).
- Move fixed_x18 handling together with retpoline handling.
- Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag.

`@bjorn3` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :)

Cc `@workingjubilee`

…n, r=nnethercote,WaffleLapkin

Extract some shared code from codegen backend target feature handling

There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`.

The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features`  does not? The second commit also cleans up a bunch of unneeded complexity added in rust-lang#135927.

The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes:
- Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes rust-lang#134792.
- The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that...
- Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway.

The fourth commit increases consistency of the GCC backend with the LLVM backend.

The last commit does some further cleanup:
- Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes rust-lang#142412.
- Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this).
- Move fixed_x18 handling together with retpoline handling.
- Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag.

``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :)

Cc ``@workingjubilee``

Rollup merge of #140920 - RalfJung:target-feature-unification, r=nnethercote,WaffleLapkin

Extract some shared code from codegen backend target feature handling

There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`.

The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features`  does not? The second commit also cleans up a bunch of unneeded complexity added in #135927.

The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes:
- Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes #134792.
- The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that...
- Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway.

The fourth commit increases consistency of the GCC backend with the LLVM backend.

The last commit does some further cleanup:
- Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes #142412.
- Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this).
- Move fixed_x18 handling together with retpoline handling.
- Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag.

``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :)

Cc ``@workingjubilee``

…twco

retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features

`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.

It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.

Also this PR forbids to specify those target features manually (warning).

Issue: rust-lang#116852

…=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: `@azhogin` `@Darksonn`

This goes on top of rust-lang#135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: rust-lang#116852.
MCP: rust-lang/compiler-team#868.

…=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: ``@azhogin`` ``@Darksonn``

This goes on top of rust-lang#135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: rust-lang#116852.
MCP: rust-lang/compiler-team#868.

…=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: `@azhogin` `@Darksonn`

This goes on top of rust-lang#135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: rust-lang#116852.
MCP: rust-lang/compiler-team#868.

…=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: `@azhogin` `@Darksonn`

This goes on top of rust-lang#135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: rust-lang#116852.
MCP: rust-lang/compiler-team#868.

…=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: ``@azhogin`` ``@Darksonn``

This goes on top of rust-lang#135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: rust-lang#116852.
MCP: rust-lang/compiler-team#868.

…=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: `@azhogin` `@Darksonn`

This goes on top of rust-lang#135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: rust-lang#116852.
MCP: rust-lang/compiler-team#868.

…=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: ``@azhogin`` ``@Darksonn``

This goes on top of rust-lang#135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: rust-lang#116852.
MCP: rust-lang/compiler-team#868.

Rollup merge of #140740 - ojeda:indirect-branch-cs-prefix, r=davidtwco

Add `-Zindirect-branch-cs-prefix`

Cc: ``@azhogin`` ``@Darksonn``

This goes on top of #135927, i.e. please skip the first commit here. Please feel free to inherit it there.

In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.

There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.

Tracking issue: #116852.
MCP: rust-lang/compiler-team#868.