Commit Graph

2953 Commits

Author SHA1 Message Date
Jacob Pratt
19b6743d95
Rollup merge of #137337 - dalvescb:master, r=petrochenkov
Add verbatim linker to AIXLinker

This adds support for the "verbatim" native link modifier on AIX, will successfully pass the `native-link-modifier-verbatim-linker test case`
2025-03-07 21:57:47 -05:00
Esteban Küber
f0dec714f3 Make some invalid codegen attr errors structured/translatable 2025-03-07 23:26:48 +00:00
Nicholas Nethercote
8a3e03392e Remove #![warn(unreachable_pub)] from all compiler/ crates.
(Except for `rustc_codegen_cranelift`.)

It's no longer necessary now that `unreachable_pub` is in the workspace
lints.
2025-03-08 08:41:43 +11:00
Nicholas Nethercote
beba32cebb Specify rust lints for compiler/ crates via Cargo.
By naming them in `[workspace.lints.rust]` in the top-level
`Cargo.toml`, and then making all `compiler/` crates inherit them with
`[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`,
because they're a bit different.)

The advantages of this over the current approach:
- It uses a standard Cargo feature, rather than special handling in
  bootstrap. So, easier to understand, and less likely to get
  accidentally broken in the future.
- It works for proc macro crates.

It's a shame it doesn't work for rustc-specific lints, as the comments
explain.
2025-03-08 08:41:09 +11:00
Thalia Archibald
38fad984c6 compiler: Use size_of from the prelude instead of imported
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.

These functions were added to all preludes in Rust 1.80.
2025-03-07 13:37:04 -08:00
Matthias Krüger
63c548d82c
Rollup merge of #137549 - oli-obk:llvm-ffi, r=davidtwco
Clean up various LLVM FFI things in codegen_llvm

cc ```@ZuseZ4``` I touched some autodiff parts

The major change of this PR is [bfd88ce](bfd88cead0) which makes `CodegenCx` generic just like `GenericBuilder`

The other commits mostly took advantage of the new feature of making extern functions safe, but also just used some wrappers that were already there and shrunk unsafe blocks.

best reviewed commit-by-commit
2025-03-07 19:15:34 +01:00
Scott McMurray
d9432acfe1 Use trunc nuw+br for 0/1 branches even in optimized builds
Rather than needing to use `switch` for them to include the `unreachable` arm
2025-03-06 22:25:49 -08:00
Nicholas Nethercote
293fe0a966 Increase recursion_limit in numerous crates.
This is temporarily needed for `x doc compiler` to work. They can be
removed once the `Nonterminal` is removed (#124141).
2025-03-07 14:51:07 +11:00
Rémy Rakic
e0b75776c3 linux x64: default to -znostart-stop-gc
This will help stabilization of lld.
2025-03-05 08:50:08 +01:00
Nicholas Nethercote
936a8232df Change signature of target_features_cfg.
Currently it is called twice, once with `allow_unstable` set to true and
once with it set to false. This results in some duplicated work. Most
notably, for the LLVM backend, `LLVMRustHasFeature` is called twice for
every feature, and it's moderately slow. For very short running
compilations on platforms with many features (e.g. a `check` build of
hello-world on x86) this is a significant fraction of runtime.

This commit changes `target_features_cfg` so it is only called once, and
it now returns a pair of feature sets. This halves the number of
`LLVMRustHasFeature` calls.
2025-03-05 09:49:17 +11:00
Nicholas Nethercote
2df8e657f2 Simplify implied_target_features.
Currently its argument is an iterator, but in practice it's always a
singleton.
2025-03-05 09:20:28 +11:00
bors
f9e0239a7b Auto merge of #135695 - Noratrieb:elf-raw-dylib, r=bjorn3
Support raw-dylib link kind on ELF

raw-dylib is a link kind that allows rustc to link against a library without having any library files present.
This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker.

While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future.

This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.

I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27
Tracking issue: #135694

r? bjorn3

try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
2025-03-04 15:39:44 +00:00
bors
fd17deacce Auto merge of #137959 - matthiaskrgr:rollup-62vjvwr, r=matthiaskrgr
Rollup of 12 pull requests

Successful merges:

 - #135767 (Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies)
 - #137852 (Remove layouting dead code for non-array SIMD types.)
 - #137863 (Fix pretty printing of unsafe binders)
 - #137882 (do not build additional stage on compiler paths)
 - #137894 (Revert "store ScalarPair via memset when one side is undef and the other side can be memset")
 - #137902 (Make `ast::TokenKind` more like `lexer::TokenKind`)
 - #137921 (Subtree update of `rust-analyzer`)
 - #137922 (A few cleanups after the removal of `cfg(not(parallel))`)
 - #137939 (fix order on shl impl)
 - #137946 (Fix docker run-local docs)
 - #137955 (Always allow rustdoc-json tests to contain long lines)
 - #137958 (triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-03-04 02:27:56 +00:00
Matthias Krüger
70b9968d1e
Rollup merge of #137894 - compiler-errors:no-scalar-pair-opt, r=oli-obk
Revert "store ScalarPair via memset when one side is undef and the other side can be memset"

cc #137892
reverts #135335

r? oli-obk
2025-03-03 20:47:12 +01:00
bors
e16a049adb Auto merge of #137914 - matthiaskrgr:rollup-phaxe6f, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #137103 ({json|html}docck: catch and error on deprecated syntax)
 - #137632 (rustdoc: when merging target features, keep the highest stability)
 - #137684 (Add rustdoc support for `--emit=dep-info[=path]`)
 - #137794 (make qnx pass a test)
 - #137801 (tests: Unignore target modifier tests on all platforms)
 - #137826 (test(codegen): add looping_over_ne_bytes test for #133528)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-03-03 19:34:25 +00:00
Matthias Krüger
962e492847
Rollup merge of #137632 - RalfJung:rustdoc-target-features, r=workingjubilee
rustdoc: when merging target features, keep the highest stability

This addresses https://github.com/rust-lang/rust/issues/137366. (Not closing since we might consider a backport.)

rustdoc wants to pretend that it runs for all targets at once and has all target features, so `tcx.rust_target_features()` will actually be all the target features. For target features that exist on multiple targets, the stability info for one of the targets will be picked (first or last in the list, I guess). All the code consuming that query has to be aware that the data is basically nonsense when running in rustdoc, but the logic checking for unstable or forbidden `#[target_feature]` attributes was not aware of that.

This PR makes the  `tcx.rust_target_features()` info in rustdoc slightly less nonsensical (and decidedly less random) by having the "most stable" target feature take precedent. That deals with #137366 (a conflict between a stable and a "forbidden" target feature of the same name for different targets), and also deals with the situation (that we did not seem to have yet) of a conflict between a stable and an unstable target feature of the same name. Note that if there are two unstable target features of the same name, rustdoc might still require the "wrong" nightly feature to be enabled -- but this can only possibly affect unstable code so I guess we can wait until that actually happens, and then someone will have to rewrite this entire thing to be less hacky.
2025-03-03 06:41:34 +01:00
Sa4dUs
6b29bb6680 Prevent ICE in autodiff validation by emitting user-friendly errors 2025-03-02 23:58:07 +01:00
Matthias Krüger
bb089d7a92
Rollup merge of #137851 - folkertdev:simd-intrinsic-mask-signed, r=workingjubilee
improve `simd_select` error message when used with invalid mask type

followup to https://github.com/rust-lang/rust/pull/137828

This PR improves the error message for an invalid `simd_select` mask type, and adds testing for `simd_scatter` and `simd_gather` being used with invalid mask types.

the `simd_masked_load` and `simd_masked_store` intrinsics already generated a better error message:

0c72c0d11a/tests/ui/simd/masked-load-store-build-fail.rs (L24-L37)

r? `@workingjubilee`
2025-03-02 22:44:25 +01:00
Michael Goulet
a59a8f9e75 Revert "Auto merge of #135335 - oli-obk:push-zxwssomxxtnq, r=saethlin"
This reverts commit a7a6c64a65, reversing
changes made to ebbe63891f.
2025-03-02 18:52:48 +00:00
Matthias Krüger
878f383118
Rollup merge of #137830 - LuigiPiucco:incompatible-isa-fix, r=workingjubilee
Fix link failure on AVR (incompatible ISA error)

Fixes #137739. A reproducer of the issue is present there. I believe the root cause was introducing the avr-none target (which has no CPU by default) while also trying to get the ISA revision from the target spec. This commit uses the `target-cpu` option instead, which is already required to be present for the target.

r? compiler
cc ``@Patryk27``
2025-03-01 16:03:20 +01:00
Matthias Krüger
3bf976542a
Rollup merge of #137804 - RalfJung:backend-repr-simd-vector, r=workingjubilee
rename BackendRepr::Vector → SimdVector

For many Rustaceans, "vector" does not imply "SIMD", so let's be more clear in this type that is used pervasively in the compiler.

r? `@workingjubilee`
2025-03-01 16:03:10 +01:00
Ralf Jung
4c939db0e7 also skip abi_required_features check in rustdoc 2025-03-01 15:14:02 +01:00
Folkert de Vries
3a6f269f26
improve error message and testing of using an unsigned simd mask 2025-03-01 12:58:22 +01:00
bors
0c72c0d11a Auto merge of #133250 - DianQK:embed-bitcode-pgo, r=nikic
The embedded bitcode should always be prepared for LTO/ThinLTO

Fixes #115344. Fixes #117220.

There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`.

When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module.

This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`.

r? nikic
2025-03-01 08:22:18 +00:00
bors
30508faeb3 Auto merge of #137796 - jieyouxu:rollup-qt9yr1g, r=jieyouxu
Rollup of 10 pull requests

Successful merges:

 - #134943 (Add FileCheck annotations to mir-opt/issues)
 - #137017 (Don't error when adding a staticlib with bitcode files compiled by newer LLVM)
 - #137197 (Update some comparison codegen tests now that they pass in LLVM20)
 - #137540 (Fix (more) test directives that were accidentally ignored)
 - #137551 (import `simd_` intrinsics)
 - #137599 (tests: use minicore more)
 - #137673 (Fix Windows `Command` search path bug)
 - #137676 (linker: Fix escaping style for response files on Windows)
 - #137693 (Re-enable `--generate-link-to-defintion` for tools internal rustdoc)
 - #137770 (Fix sized constraint for unsafe binder)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-03-01 00:53:19 +00:00
Luigi Sartor Piucco
4c1f51bf6e
Fix link failure on AVR (incompatible ISA error)
Fixes #137739. A reproducer of the issue is present there. I believe the
root cause was introducing the avr-none target (which has no CPU by
default) and trying to get the ISA revision from there. This commit
uses the `target-cpu` option instead, which is already required to be
present for the target.

Co-authored-by: tones111 <tones111@users.noreply.github.com>
2025-02-28 18:27:35 -03:00
Ralf Jung
aac65f562b rename BackendRepr::Vector → SimdVector 2025-02-28 17:17:45 +01:00
许杰友 Jieyou Xu (Joe)
f1cdd3be01
Rollup merge of #137676 - petrochenkov:winresp, r=Kobzol
linker: Fix escaping style for response files on Windows

If we use a С/С++ compiler as linker, then Posix-style escaping should be used.

Also temporarily fixup rustbuild to not fail at least in common scenarios, until the bootstrap compiler is updated.

Fixes https://github.com/rust-lang/rust/issues/137498
2025-02-28 22:29:54 +08:00
许杰友 Jieyou Xu (Joe)
e3f42aa59f compiler: bump cc to 1.2.16 to fix x86 Windows jobs on newest Windows SDK
See <https://github.com/rust-lang/rust/issues/137733>.
2025-02-28 21:10:21 +08:00
Noratrieb
a954c51280 Support raw-dylib link kind on ELF
raw-dylib is a link kind that allows rustc to link against a library
without having any library files present.
This currently only exists on Windows. rustc will take all the symbols
from raw-dylib link blocks and put them in an import library, where they
can then be resolved by the linker.

While import libraries don't exist on ELF, it would still be convenient
to have this same functionality. Not having the libraries present at
build-time can be convenient for several reasons, especially
cross-compilation. With raw-dylib, code linking against a library can be
cross-compiled without needing to have these libraries available on the
build machine. If the libc crate makes use of this, it would allow
cross-compilation without having any libc available on the build
machine. This is not yet possible with this implementation, at least
against libc's like glibc that use symbol versioning.
The raw-dylib kind could be extended with support for symbol versioning
in the future.

This implementation is very experimental and I have not tested it very
well. I have tested it for a toy example and the lz4-sys crate, where it
was able to successfully link a binary despite not having a
corresponding library at build-time.
2025-02-26 19:09:51 +01:00
León Orell Valerian Liehr
5da5c37387
Rollup merge of #137201 - estebank:structured-errors-long-ty, r=oli-obk
Teach structured errors to display short `Ty<'_>`

Make it so that in every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to.

```
error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)``
 --> long.rs:7:5
  |
6 | fn foo(x: D) { //~ `x` has type `(...
  |        - `x` has type `((..., ..., ..., ...), ..., ..., ...)`
7 |     x(); //~ ERROR expected function, found `(...
  |     ^--
  |     |
  |     call expression requires function
  |
  = note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt'
  = note: consider using `--verbose` to print the full type name to the console
```

Follow up to and response to the comments on #136898.

r? ``@oli-obk``
2025-02-26 19:03:55 +01:00
Vadim Petrochenkov
9a2362a76e linker: Fix escaping style for response files on Windows
If we use a С/С++ compiler as linker, then Posix-style escaping should be used.
2025-02-26 17:45:08 +03:00
León Orell Valerian Liehr
51085b21ce
Rollup merge of #137601 - davidtwco:deduplicate-type-has-metadata, r=fmease,bjorn3
ssa/mono: deduplicate `type_has_metadata`

The implementation of the `type_has_metadata` function is duplicated in `rustc_codegen_ssa` and `rustc_monomorphize`, so move this to `rustc_middle`.
2025-02-26 04:15:05 +01:00
León Orell Valerian Liehr
1cdd38666b
Rollup merge of #136576 - usamoi:pass-more-llbc, r=fmease
pass optimization level to llvm-bitcode-linker

optimization level is not passed to llbc, which should be a mistake
2025-02-26 04:15:01 +01:00
Ralf Jung
039af88e09 also fix potential issues with mixed stable/unstable target features in rustdoc 2025-02-25 20:38:13 +01:00
Ralf Jung
b6f2240000 rustdoc: disable forbidden #[target_feature] check 2025-02-25 20:26:12 +01:00
Esteban Küber
d12ecaed55 Teach structured errors to display short Ty
Make it so that every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to.

```
error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)``
 --> long.rs:7:5
  |
6 | fn foo(x: D) { //~ `x` has type `(...
  |        - `x` has type `((..., ..., ..., ...), ..., ..., ...)`
7 |     x(); //~ ERROR expected function, found `(...
  |     ^--
  |     |
  |     call expression requires function
  |
  = note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt'
  = note: consider using `--verbose` to print the full type name to the console
```
2025-02-25 16:56:03 +00:00
bors
c51b9b6d52 Auto merge of #133832 - madsmtm:apple-symbols.o, r=DianQK
Make `#[used]` work when linking with `ld64`

To make `#[used]` work in static libraries, we use the `symbols.o` trick introduced in https://github.com/rust-lang/rust/pull/95604.

However, the linker shipped with Xcode, ld64, works a bit differently from other linkers; in particular, [it completely ignores undefined symbols by themselves](https://github.com/apple-oss-distributions/ld64/blob/ld64-954.16/src/ld/parsers/macho_relocatable_file.cpp#L2455-L2468), and only consider them if they have relocations (something something atoms something fixups, I don't know the details).

So to make the `symbols.o` file work on ld64, we need to actually insert a relocation. That's kinda cumbersome to do though, since the relocation must be valid, and hence must point to a valid piece of machine code, and is hence very architecture-specific.

Fixes https://github.com/rust-lang/rust/issues/133491, see that for investigation.

---

Another option would be to pass `-u _foo` to the final linker invocation. This has the problem that `-u` causes the linker to not be able to dead-strip the symbol, which is undesirable. (If we did this, we would possibly also want to do it by putting the arguments in a file by itself, and passing that file via ``@`,` e.g. ``@undefined_symbols.txt`,` similar to https://github.com/rust-lang/rust/issues/52699, though that [is only supported since Xcode 12](https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes#Linking), and I'm not sure we wanna bump that).

Various other options that are probably all undesirable as they affect link time performance:
- Pass `-all_load` to the linker.
- Pass `-ObjC` to the linker (the Objective-C support in the linker has different code paths that load more of the binary), and instrument the binaries that contain `#[used]` symbols.
- Pass `-force_load` to libraries that contain `#[used]` symbols.

Failed attempt: Embed `-u _foo` in the object file with `LC_LINKER_OPTION`, akin to https://github.com/rust-lang/rust/issues/121293. Doesn't work, both because `ld64` doesn't read that from archive members unless it already has a reason to load the member (which is what this PR is trying to make it do), and because `ld64` only support the `-l`, `-needed-l`, `-framework` and `-needed_framework` flags in there.

---

TODO:
- [x] Support all Apple architectures.
- [x] Ensure that this works regardless of the actual type of the symbol.
- [x] Write up more docs.
- [x] Wire up a few proper tests.

`@rustbot` label O-apple
2025-02-25 11:59:11 +00:00
bors
7d8c6e781d Auto merge of #135726 - jdonszelmann:attr-parsing, r=oli-obk
New attribute parsing infrastructure

Another step in the plan outlined in https://github.com/rust-lang/rust/issues/131229

introduces infrastructure for structured parsers for attributes, as well as converting a couple of complex attributes to have such structured parsers.

This PR may prove too large to review. I left some of my own comments to guide it a little. Some general notes:

- The first commit is basically standalone. It just preps some mostly unrelated sources for the rest of the PR to work. It might not have enormous merit on its own, but not negative merit either. Could be merged alone, but also doesn't make the review a whole lot easier. (but it's only +274 -209)
- The second commit is the one that introduces new infrastructure. It's the important one to review.
- The 3rd commit uses the new infrastructure showing how some of the more complex attributes can be parsed using it. Theoretically can be split up, though the parsers in this commit are the ones that really test the new infrastructure and show that it all works.
- The 4th commit fixes up rustdoc and clippy. In the previous 2 they didn't compile yet while the compiler does. Separated them out to separate concerns and make the rest more palatable.
- The 5th commit blesses some test outputs. Sometimes that's just because a diagnostic happens slightly earlier than before, which I'd say is acceptable. Sometimes a diagnostic is now only emitted once where it would've been twice before (yay! fixed some bugs). One test I actually moved from crashes to fixed, because it simply doesn't crash anymore. That's why this PR  Closes #132391. I think most choices I made here are generally reasonable, but let me know if you disagree anywhere.
- The 6th commit adds a derive to pretty print attributes
- The 7th removes smir apis for attributes, for the time being. The api will at some point be replaced by one based on `rustc_ast_data_structures::AttributeKind`

In general, a lot of the additions here are comments. I've found it very important to document new things in the 2nd commit well so other people can start using it.

Closes #132391
Closes #136717
2025-02-24 23:07:24 +00:00
Oli Scherer
29440b84a9 Remove an unused lifetime param 2025-02-24 15:11:29 +00:00
Oli Scherer
840e31b29f Generalize BaseTypeCodegenMethods 2025-02-24 15:11:29 +00:00
Oli Scherer
d4379d2afd Remove an unnecessary lifetime 2025-02-24 15:05:56 +00:00
Jana Dönszelmann
7e0f5b5016
Introduce new-style attribute parsers for several attributes
note: compiler compiles but librustdoc and clippy don't
2025-02-24 14:31:17 +01:00
Jana Dönszelmann
dbd3b7928e
Introduce new parsing infrastructure and types for parsed attributes
fixup docs in parser
2025-02-24 14:26:06 +01:00
Jana Dönszelmann
115b3b03b0
Change span field accesses to method calls 2025-02-24 14:22:31 +01:00
David Wood
5afa6a111b
ssa/mono: deduplicate type_has_metadata
The implementation of the `type_has_metadata` function is duplicated in
`rustc_codegen_ssa` and `rustc_monomorphize`, so move this to
`rustc_middle`.
2025-02-24 08:08:23 +00:00
Scott McMurray
23c6b93de8 Don't re-assume in transmutes that don't change niches 2025-02-23 23:18:04 -08:00
Jacob Pratt
42014b44b3
Rollup merge of #137505 - tgross35:builtins-cannot-call-error, r=compiler-errors
Add a span to `CompilerBuiltinsCannotCall`

Currently, this error emit a diagnostic with no context like:

    error: `compiler_builtins` cannot call functions through upstream monomorphizations; encountered invalid call from `<math::libm::support::hex_float::Hexf<i32> as core::fmt::LowerHex>::fmt` to `core::fmt::num::<impl core::fmt::LowerHex for i32>::fmt`

With this change, it at least usually points to the problematic function:

    error: `compiler_builtins` cannot call functions through upstream monomorphizations; encountered invalid call from `<math::libm::support::hex_float::Hexf<i32> as core::fmt::LowerHex>::fmt` to `core::fmt::num::<impl core::fmt::LowerHex for i32>::fmt`
       --> src/../libm/src/math/support/hex_float.rs:270:5
        |
    270 |     fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        |
2025-02-24 02:11:38 -05:00
Jacob Pratt
6aa015ae9d
Rollup merge of #136610 - Jarcho:range_idx, r=Noratrieb
Allow `IndexSlice` to be indexed by ranges.

This comes with some annoyances as the index type can no longer inferred from indexing expressions. The biggest offender for this is `IndexVec::from_fn_n(|idx| ..., n)` where the index type won't be inferred from the call site or any index expressions inside the closure.

My main use case for this is mapping a `Place` to `Range<Idx>` for value tracking where the range represents all the values the place contains.
2025-02-24 02:11:32 -05:00
Trevor Gross
7a2db88a56 Add a span to CompilerBuiltinsCannotCall
Currently, this error emit a diagnostic with no context like:

    error: `compiler_builtins` cannot call functions through upstream monomorphizations; encountered invalid call from `<math::libm::support::hex_float::Hexf<i32> as core::fmt::LowerHex>::fmt` to `core::fmt::num::<impl core::fmt::LowerHex for i32>::fmt`

With this change, it at least usually points to the problematic
function:

    error: `compiler_builtins` cannot call functions through upstream monomorphizations; encountered invalid call from `<math::libm::support::hex_float::Hexf<i32> as core::fmt::LowerHex>::fmt` to `core::fmt::num::<impl core::fmt::LowerHex for i32>::fmt`
       --> src/../libm/src/math/support/hex_float.rs:270:5
        |
    270 |     fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        |
2025-02-24 03:33:16 +00:00
bors
e0be1a0262 Auto merge of #137271 - nikic:gep-nuw-2, r=scottmcm
Emit getelementptr inbounds nuw for pointer::add()

Lower pointer::add (via intrinsic::offset with unsigned offset) to getelementptr inbounds nuw on LLVM versions that support it. This lets LLVM make use of the pre-condition that the offset addition does not wrap in an unsigned sense. Together with inbounds, this also implies that the offset is non-negative.

Fixes https://github.com/rust-lang/rust/issues/137217.
2025-02-24 03:06:16 +00:00
Mads Marquart
b202430084 Make #[used] work when linking with ld64 2025-02-24 04:04:59 +01:00
Trevor Gross
2c6fa32bdc
Rollup merge of #136637 - Pyr0de:binary-format, r=Noratrieb
Add binary_format to rustc target specs

Added binary format field to `TargetOptions`

Fixes #135724

r? `@Noratrieb`
2025-02-23 14:30:26 -05:00
Trevor Gross
31719b59c8
Rollup merge of #136439 - yotamofek:pr/codegen-ssa-no-indexing, r=Noratrieb
Misc. `rustc_codegen_ssa` cleanups 🧹

Just a bunch of stuff I found while reading the crate's code.
Each commit can stand on its own.
Maybe r? `@Noratrieb` because I saw you did some similar cleanups on these files a while ago? (feel free to re-assign, I'm just guessing)
2025-02-23 14:30:24 -05:00
DianQK
a897cc0351
Remove unused OutputType::ThinLinkBitcode 2025-02-23 21:23:38 +08:00
DianQK
da50297a6e
Save pre-link bitcode to ModuleCodegen 2025-02-23 21:23:38 +08:00
DianQK
9431427cc3
Add new_regular and new_allocator to ModuleCodegen 2025-02-23 21:23:38 +08:00
DianQK
1a99ca8da9
The embedded bitcode should always be prepared for LTO/ThinLTO 2025-02-23 21:23:36 +08:00
Matthias Krüger
4115f51d15
Rollup merge of #137180 - compiler-errors:sym-regions, r=oli-obk
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes

There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.

Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).

Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:

```rust
fn foo<'a>() {
  asm!("/* ... */", sym bar::<&'a ()>);
}
```

The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.

In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.

I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (https://github.com/rust-lang/rust/issues/137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to https://github.com/rust-lang/rust/pull/130443#issuecomment-2445678945, which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.

As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).

r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.

Fixes #111709
Fixes #96304
Fixes #137179
2025-02-23 00:16:19 +01:00
bors
15469f8f8a Auto merge of #137420 - matthiaskrgr:rollup-rr0q37f, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #136910 (Implement feature `isolate_most_least_significant_one` for integer types)
 - #137183 (Prune dead regionck code)
 - #137333 (Use `edition = "2024"` in the compiler (redux))
 - #137356 (Ferris 🦀 Identifier naming conventions)
 - #137362 (Add build step log for `run-make-support`)
 - #137377 (Always allow reusing cratenum in CrateLoader::load)
 - #137388 (Fix(lib/fs/tests): Disable rename POSIX semantics FS tests under Windows 7)
 - #137410 (Use StableHasher + Hash64 for dep_tracking_hash)
 - #137413 (jubilee cleared out the review queue)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-22 13:32:44 +00:00
Manuel Drehwald
e2d250c3f6 update autodiff flags 2025-02-21 21:51:20 -05:00
Michael Goulet
3d5438accd Fix binding mode problems 2025-02-22 00:13:19 +00:00
Michael Goulet
6ba39f7dc7 Make a fake body to store typeck results for global_asm 2025-02-22 00:12:07 +00:00
Michael Goulet
2a6daaf89a Make asm a named field 2025-02-22 00:05:09 +00:00
Michael Goulet
76d341fa09 Upgrade the compiler to edition 2024 2025-02-22 00:01:48 +00:00
Jason Newcomb
162fb713ac Allow SliceIndex to be indexed by ranges. 2025-02-21 16:10:31 -05:00
usamoi
123062bfd9 pass optimization level to llvm-bitcode-linker 2025-02-21 19:38:00 +08:00
Scott McMurray
da77b39f05 Refactor OperandRef::extract_field to prep for 838 2025-02-20 22:26:24 -08:00
Jubilee
8c9e3749a1
Rollup merge of #136985 - zachs18:backend-repr-remove-uninhabited, r=workingjubilee
Do not ignore uninhabited types for function-call ABI purposes. (Remove BackendRepr::Uninhabited)

Accepted MCP: https://github.com/rust-lang/compiler-team/issues/832

Fixes #135802

Do not consider the inhabitedness of a type for function call ABI purposes.

* Remove the [`rustc_abi::BackendRepr::Uninhabited`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html) variant
  * Instead calculate the `BackendRepr` of uninhabited types "normally" (as though they were not uninhabited "at the top level", but still considering inhabitedness of variants to determine enum layout, etc)
* Add an `uninhabited: bool` field to [`rustc_abi::LayoutData`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/struct.LayoutData.html) so inhabitedness of a `LayoutData` can still be queried when necessary (e.g. when determining if an enum variant needs a tag value allocated to it).

This should not affect type layouts (size/align/field offset); this should only affect function call ABI, and only of uninhabited types.

cc ``@RalfJung``
2025-02-20 14:58:18 -08:00
Jubilee
6d74563b20
Rollup merge of #136608 - kulst:ptx_target_features, r=bjorn3
Pass through of target features to llvm-bitcode-linker and handling them

When using the llvm-bitcode-linker (`linker-flavor=llbc`) target-features are not passed through and are not handled by it.
The llvm-bitcode-linker is mainly used as a self contained linker to link llvm bitcode for the nvptx64 target. It uses `llvm-link`, `opt` and `llc` internally. To produce a `.ptx` file of a specific ptx-version it is necessary to pass the version to llc with the `--mattr` option. Without explicitly setting it, the emitted `.ptx`-version is the minimum supported version of the `--target-cpu`.

I would like to be able to explicitly set the ptx version as [some llvm problems only occur in earlier `.ptx`-versions](https://github.com/llvm/llvm-project/issues/112998).

Therefore this pull request adds support for passing target features to llvm-bitcode-linker and handling them.
I was not quite sure if adding these features to `rustc_target/src/target_features.rs` is necessary or not. If so I will gladly add these.

    r? ``@kjetilkjeka``
2025-02-20 14:58:17 -08:00
Jubilee
9de94b4f8f
Rollup merge of #131651 - Patryk27:avr-unknown-unknown, r=tgross35
Create a generic AVR target: avr-none

This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-none` variant that must be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`).

Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official 🙂

Related discussions:
- https://github.com/rust-lang/rust/pull/131171
- https://github.com/rust-lang/compiler-team/issues/800

try-job: x86_64-gnu-debug
2025-02-20 14:58:15 -08:00
Zachary S
58ebf6afdd Add test that uninhabited repr(transparent) type has same function return ABI as wrapped type.
Fix codegen of uninhabited PassMode::Indirect return types.

Add codegen test for uninhabited PassMode::Indirect return types.

Enable optimizations for uninhabited return type codegen test
2025-02-20 13:41:11 -06:00
Curtis D'Alves
917d2eb78a add verbatim linker to AIXLinker 2025-02-20 14:31:19 -05:00
Zachary S
7ba3d7b54e Remove BackendRepr::Uninhabited, replaced with an uninhabited: bool field in LayoutData.
Also update comments that refered to BackendRepr::Uninhabited.
2025-02-20 13:27:32 -06:00
Scott McMurray
6f9cfd694d Rework OperandRef::extract_field to stop calling to_immediate_scalar on things which are already immediates
That means it stops trying to truncate things that are already `i1`s.
2025-02-19 12:03:40 -08:00
Scott McMurray
511bf307f0 Emit trunc nuw for unchecked shifts and to_immediate_scalar
- For shifts this shrinks the IR by no longer needing an `assume` while still providing the UB information
- Having this on the `i8`→`i1` truncations will hopefully help with some places that have to load `i8`s or pass those in LLVM structs without range information
2025-02-19 11:36:52 -08:00
Patryk Wychowaniec
78ddabf31d
Create a generic AVR target: avr-none
This commit removes the `avr-unknown-gnu-atmega328` target and replaces
it with a more generic `avr-none` variant that must be specialized with
the `-C target-cpu` flag (e.g. `-C target-cpu=atmega328p`).
2025-02-19 19:01:51 +01:00
Nikita Popov
9e7b1847dc Also use gep inbounds nuw for index projections 2025-02-19 15:15:29 +01:00
Nikita Popov
31cc4c074d Emit getelementptr inbounds nuw for pointer::add() 2025-02-19 11:32:32 +01:00
Matthias Krüger
34535b6078
Rollup merge of #137213 - nnethercote:rm-rustc_middle-mir-tcx, r=compiler-errors
Remove `rustc_middle::mir::tcx` module.

This is a really weird module. For example, what does `tcx` in `rustc_middle::mir::tcx::PlaceTy` mean? The answer is "not much".

The top-level module comment says:

> Methods for the various MIR types. These are intended for use after
> building is complete.

Awfully broad for a module that has a handful of impl blocks for some MIR types, none of which really relates to `TyCtxt`. `git blame` indicates the comment is ancient, from 2015, and made sense then.

This module is now vestigial. This commit removes it and moves all the code within into `rustc_middle::mir::statement`. Some specifics:

- `Place`, `PlaceRef`, `Rvalue`, `Operand`, `BorrowKind`: they all have `impl` blocks in both the `tcx` and `statement` modules. The commit merges the former into the latter.

- `BinOp`, `UnOp`: they only have `impl` blocks in `tcx`. The commit moves these into `statement`.

- `PlaceTy`, `RvalueInitializationState`: they are defined in `tcx`. This commit moves them into `statement` *and* makes them available in `mir::*`, like many other MIR types.

r? `@tmandry`
2025-02-19 01:30:13 +01:00
Nicholas Nethercote
5d1551b9c6 Remove rustc_middle::mir::tcx module.
This is a really weird module. For example, what does `tcx` in
`rustc_middle::mir::tcx::PlaceTy` mean? The answer is "not much".

The top-level module comment says:

> Methods for the various MIR types. These are intended for use after
> building is complete.

Awfully broad for a module that has a handful of impl blocks for some
MIR types, none of which really relates to `TyCtxt`. `git blame`
indicates the comment is ancient, from 2015, and made sense then.

This module is now vestigial. This commit removes it and moves all the
code within into `rustc_middle::mir::statement`. Some specifics:

- `Place`, `PlaceRef`, `Rvalue`, `Operand`, `BorrowKind`: they all have `impl`
  blocks in both the `tcx` and `statement` modules. The commit merges
  the former into the latter.

- `BinOp`, `UnOp`: they only have `impl` blocks in `tcx`. The commit
  moves these into `statement`.

- `PlaceTy`, `RvalueInitializationState`: they are defined in `tcx`.
  This commit moves them into `statement` *and* makes them available in
  `mir::*`, like many other MIR types.
2025-02-19 10:26:05 +11:00
bors
3b022d8cee Auto merge of #133852 - x17jiri:cold_path, r=saethlin
improve cold_path()

#120370 added a new instrinsic `cold_path()` and used it to fix `likely` and `unlikely`

However, in order to limit scope, the information about cold code paths is only used in 2-target switch instructions. This is sufficient for `likely` and `unlikely`, but limits usefulness of `cold_path` for idiomatic rust. For example, code like this:

```
if let Some(x) = y { ... }
```

may generate 3-target switch:

```
switch y.discriminator:
0 => true branch
1 = > false branch
_ => unreachable
```

and therefore marking a branch as cold will have no effect.

This PR improves `cold_path()` to work with arbitrary switch instructions.

Note that for 2-target switches, we can use `llvm.expect`, but for multiple targets we need to manually emit branch weights. I checked Clang and it also emits weights in this situation. The Clang's weight calculation is more complex that this PR, which I believe is mainly because `switch` in `C/C++` can have multiple cases going to the same target.
2025-02-18 07:49:09 +00:00
Pyrode
17f2928caa Adds binary_format to rustc target specs 2025-02-17 20:32:12 +05:30
bors
2162e9d4b1 Auto merge of #137164 - matthiaskrgr:rollup-dj5826k, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #137095 (Replace some u64 hashes with Hash64)
 - #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
 - #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
 - #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
 - #137125 (Re-add missing empty lines in the releases notes)
 - #137145 (use add-core-stubs / minicore for a few more tests)
 - #137149 (Remove SSE ABI from i586-pc-windows-msvc)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-17 11:18:33 +00:00
Jiri Bobek
7bb5f4dd78 improve cold_path() 2025-02-17 06:39:58 +01:00
Matthias Krüger
fab38375bc
Rollup merge of #137095 - saethlin:use-hash64-for-hashes, r=workingjubilee
Replace some u64 hashes with Hash64

I introduced the Hash64 and Hash128 types in https://github.com/rust-lang/rust/pull/110083, essentially as a mechanism to prevent hashes from landing in our leb128 encoding paths. If you just have a u64 or u128 field in a struct then derive Encodable/Decodable, that number gets leb128 encoding. So if you need to store a hash or some other value which behaves very close to a hash, don't store it as a u64.

This reverts part of https://github.com/rust-lang/rust/pull/117603, which turned an encoded Hash64 into a u64.

Based on https://github.com/rust-lang/rust/pull/110083, I don't expect this to be perf-sensitive on its own, though I expect that it may help stabilize some of the small rmeta size fluctuations we currently see in perf reports.
2025-02-17 06:38:14 +01:00
Nicholas Nethercote
f86f7ad5f2 Move some Map methods onto TyCtxt.
The end goal is to eliminate `Map` altogether.

I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
2025-02-17 13:21:02 +11:00
Ben Kimock
4cf21866e8 Move hashes from rustc_data_structure to rustc_hashes so they can be shared with rust-analyzer 2025-02-16 16:18:30 -05:00
kulst
831d9f39e9 Pass through of target features to llvm-bitcode-linker and handling them
The .ptx version produced by llc can be specified by passing it with --mattr. Currently it is not possible to specify the .ptx version with -Ctarget-feature because these are not passed through to llvm-bitcode-linker and handled by it. This commit adds both.
--target-feature and -mattr are passed with equals to mitigate issues when the value starts with a - (minus).
2025-02-16 21:57:03 +01:00
kulst
2445dd794e Persist target features used for codegen beyond tcx
Bitcode linkers like llvm-bitcode-linker or bpf linker hand over the target features to llvm during link stage. During link stage the `TyCtxt` is already gone so it is not possible to create a query for the global backend features any longer. The features preserved in `Session.target_features` only incorporate target features known to rustc. This would contradict with the behaviour during codegen stage which also passes target features to llvm which are unknown to rustc.
This commit adds target features as a field to the `CrateInfo` struct and queries the target features in its new function. This way the target features are preserved beyond tcx and available at link stage.
To make sure the `global_backend_features` query is always registered even if the CodegenBackend does not register it, this registration is added to the `provide`function of the `rustc_codegen_ssa` crate.
2025-02-16 21:57:03 +01:00
Jacob Pratt
20004d4bdd
Rollup merge of #135909 - Flakebi:amdgpu-kd, r=jieyouxu,workingjubilee
Export kernel descriptor for amdgpu kernels

The host runtime (HIP or HSA) expects a kernel descriptor object for each kernel in the ELF file. The amdgpu LLVM backend generates the object. It is created as a symbol with the name of the kernel plus a `.kd` suffix.

Add it to the exported symbols in the linker script, so that it can be found.

For reference, the symbol is created here in LLVM: d5457e4c16/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp (L966)
I wrote [a test](6a9115b121) for this as well, I’ll add that once the target is merged and working.
With this, all PRs to get working code for amdgpu are open (this + the target + the two patches adding addrspacecasts for alloca and global variables).

Tracking issue: #135024

r? `@workingjubilee`
2025-02-16 00:51:24 -05:00
bors
bdc97d1046 Auto merge of #136575 - scottmcm:nsuw-math, r=nikic
Set both `nuw` and `nsw` in slice size calculation

There's an old note in the code to do this, and now that [LLVM-C has an API for it](f0b8ff1251/llvm/include/llvm-c/Core.h (L4403-L4408)), we might as well.  And it's been there since what looks like LLVM 17 de9b6aa341 so doesn't even need to be conditional.

(There's other places, like `RawVecInner` or `Layout`, that might want to do things like this too, but I'll leave those for a future PR.)
2025-02-14 14:21:29 +00:00
bors
d88ffcdb8b Auto merge of #136735 - scottmcm:transmute-nonnull, r=oli-obk
`transmute` should also assume non-null pointers

Previously it only did integer-ABI things, but this way it does data pointers too.  That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
2025-02-14 09:06:17 +00:00
Scott McMurray
9ad6839f7a Set both nuw and nsw in slice size calculation
There's an old note in the code to do this, and now that LLVM-C has an API for it, we might as well.
2025-02-13 21:26:48 -08:00
clubby789
2966256133 Make -O mean -C opt-level=3 2025-02-13 19:47:55 +00:00
Scott McMurray
0cc14b688d transmute should also assume non-null pointers
Previously it only did integer-ABI things, but this way it does data pointers too.  That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
2025-02-12 23:01:27 -08:00
bors
9fcc9cf4a2 Auto merge of #136954 - jhpratt:rollup-koefsot, r=jhpratt
Rollup of 12 pull requests

Successful merges:

 - #134090 (Stabilize target_feature_11)
 - #135025 (Cast allocas to default address space)
 - #135841 (Reject `?Trait` bounds in various places where we unconditionally warned since 1.0)
 - #136217 (Mark condition/carry bit as clobbered in C-SKY inline assembly)
 - #136699 (std: replace the `FromInner` implementation for addresses with private conversion functions)
 - #136806 (Fix cycle when debug-printing opaque types from RPITIT)
 - #136807 (compiler: internally merge `PtxKernel` into `GpuKernel`)
 - #136818 (Implement `read*_exact` for `std:io::repeat`)
 - #136927 (Correctly escape hashtags when running `invalid_rust_codeblocks` lint)
 - #136937 (Update books)
 - #136945 (Add diagnostic item for `std::io::BufRead`)
 - #136947 (Reinstate nnethercote in the review rotation.)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-13 02:13:24 +00:00
Jacob Pratt
575405161f
Rollup merge of #134090 - veluca93:stable-tf11, r=oli-obk
Stabilize target_feature_11

# Stabilization report

This is an updated version of https://github.com/rust-lang/rust/pull/116114, which is itself a redo of https://github.com/rust-lang/rust/pull/99767. Most of this commit and report were copied from those PRs. Thanks ```@LeSeulArtichaut``` and ```@calebzulawski!```

## Summary
Allows for safe functions to be marked with `#[target_feature]` attributes.

Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot *generally* be assigned to safe function pointers, and don't implement the `Fn*` traits.

However, calling them from other `#[target_feature]` functions with a superset of features is safe.

```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}

fn foo() {
    // Calling `avx2` here is unsafe, as we must ensure
    // that AVX is available first.
    unsafe {
        avx2();
    }
}

#[target_feature(enable = "avx2")]
fn bar() {
    // Calling `avx2` here is safe.
    avx2();
}
```

Moreover, once https://github.com/rust-lang/rust/pull/135504 is merged, they can be converted to safe function pointers in a context in which calling them is safe:

```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}

fn foo() -> fn() {
    // Converting `avx2` to fn() is a compilation error here.
    avx2
}

#[target_feature(enable = "avx2")]
fn bar() -> fn() {
    // `avx2` coerces to fn() here
    avx2
}
```

See the section "Closures" below for justification of this behaviour.

## Test cases
Tests for this feature can be found in [`tests/ui/target_feature/`](f6cb952dc1/tests/ui/target-feature).

## Edge cases
### Closures
 * [target-feature 1.1: should closures inherit target-feature annotations? #73631](https://github.com/rust-lang/rust/issues/73631)

Closures defined inside functions marked with #[target_feature] inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits.

```rust
#[target_feature(enable = "avx2")]
fn qux() {
    let my_closure = || avx2(); // this call to `avx2` is safe
    let f: fn() = my_closure;
}
```
This means that in order to call a function with #[target_feature], you must guarantee that the target-feature is available while the function, any closures defined inside it, as well as any safe function pointers obtained from target-feature functions inside it, execute.

This is usually ensured because target features are assumed to never disappear, and:
- on any unsafe call to a `#[target_feature]` function, presence of the target feature is guaranteed by the programmer through the safety requirements of the unsafe call.
- on any safe call, this is guaranteed recursively by the caller.

If you work in an environment where target features can be disabled, it is your responsibility to ensure that no code inside a target feature function (including inside a closure) runs after this (until the feature is enabled again).

**Note:** this has an effect on existing code, as nowadays closures do not inherit features from the enclosing function, and thus this strengthens a safety requirement. It was originally proposed in #73631 to solve this by adding a new type of UB: “taking a target feature away from your process after having run code that uses that target feature is UB” .
This was motivated by userspace code already assuming in a few places that CPU features never disappear from a program during execution (see i.e. 2e29bdf908/crates/std_detect/src/detect/arch/x86.rs); however, concerns were raised in the context of the Linux kernel; thus, we propose to relax that requirement to "causing the set of usable features to be reduced is unsafe; when doing so, the programmer is required to ensure that no closures or safe fn pointers that use removed features are still in scope".

* [Fix #[inline(always)] on closures with target feature 1.1 #111836](https://github.com/rust-lang/rust/pull/111836)

Closures accept `#[inline(always)]`, even within functions marked with `#[target_feature]`. Since these attributes conflict, `#[inline(always)]` wins out to maintain compatibility.

### ABI concerns
* [The extern "C" ABI of SIMD vector types depends on target features #116558](https://github.com/rust-lang/rust/issues/116558)

The ABI of some types can change when compiling a function with different target features. This could have introduced unsoundness with target_feature_11, but recent fixes (#133102, #132173) either make those situations invalid or make the ABI no longer dependent on features. Thus, those issues should no longer occur.

### Special functions
The `#[target_feature]` attribute is forbidden from a variety of special functions, such as main, current and future lang items (e.g. `#[start]`, `#[panic_handler]`), safe default trait implementations and safe trait methods.

This was not disallowed at the time of the first stabilization PR for target_features_11, and resulted in the following issues/PRs:
* [`#[target_feature]` is allowed on `main` #108645](https://github.com/rust-lang/rust/issues/108645)
* [`#[target_feature]` is allowed on default implementations #108646](https://github.com/rust-lang/rust/issues/108646)
* [#[target_feature] is allowed on #[panic_handler] with target_feature 1.1 #109411](https://github.com/rust-lang/rust/issues/109411)
* [Prevent using `#[target_feature]` on lang item functions #115910](https://github.com/rust-lang/rust/pull/115910)

## Documentation
 * Reference: [Document the `target_feature_11` feature reference#1181](https://github.com/rust-lang/reference/pull/1181)
---

cc tracking issue https://github.com/rust-lang/rust/issues/69098
cc ```@workingjubilee```
cc ```@RalfJung```
r? ```@rust-lang/lang```
2025-02-12 20:09:56 -05:00
bors
6dce9f8c2d Auto merge of #135994 - 1c3t3a:rename-unsafe-ptr, r=oli-obk
Rename rustc_middle::Ty::is_unsafe_ptr to is_raw_ptr

The wording unsafe pointer is less common and not mentioned in a lot of places, instead this is usually called a "raw pointer". For the sake of uniformity, we rename this method.
This came up during the review of
https://github.com/rust-lang/rust/pull/134424.

r? `@Noratrieb`
2025-02-12 23:18:14 +00:00
Flakebi
99ec64c34c
Export kernel descriptor for amdgpu kernels
The host runtime (HIP or HSA) expects a kernel descriptor object for
each kernel in the ELF file. The amdgpu LLVM backend generates the
object. It is created as a symbol with the name of the kernel plus a
`.kd` suffix.

Add it to the exported symbols in the linker script, so that it can be
found.
2025-02-12 22:44:39 +01:00