compiler: fn ptrs should hit different lints based on ABI
I was looking closer at the code for linting on ABIs and realized a mistake was probably made during rebase or review. I think that for function pointers in the HIR, the lint that fires should probably depend on the ABI we encountered, e.g. if it's on the newly-deprecated set of ABIs or not. This will be slightly confusing for a little bit, but I think we can do more to reduce that confusion by switching `unsupported_fn_ptr_calling_conventions` to a hard error.
r? ``@RalfJung``
Mark `core::slice::memchr` as `#[doc(hidden)]`
It's purely internal, and not intended to be a public API, even on nightly. This stops it showing up and being misleading in rustdoc search.
It also mirrors the (also internal) `core::slice::sort` module.
platform-support.md: Mention specific Linux kernel version or later
To be consistent with notes for other targets...
~~(Only made the change for `aarch64-unknown-linux-gnu` for now, as that's fairly certain after looking at the `git blame` just to be sure.)~~
deduplicate the rest of AST walker functions
After this, we can tidy things up and deduplicate the visitor traits themselves too.
Fixesrust-lang/rust#139825, apparently
r? ``@oli-obk``
docs: Small clarification on the usage of read_to_string and read_to_end trait methods
Small clarification on the usage of read_to_string and read_to_end trait methods. The goal is to make it clear that these trait methods will become locked up if attempting to read to the end of stdin (which is a bit non-sensical unless the other end closes the pipe).
Fixes: rust-lang/rust#141714
core::ptr: deduplicate more method docs
used `rg -Fxf library/core/src/ptr/{const,mut}_ptr.rs` to find duplicated doc comments, and `diff -u` after copying them to files to ensure they are actually identical.
`sed 's| */// *||'` was then used to translate the doc comments to plain markdown.
part of https://github.com/rust-lang/rust/issues/139190
use `#[naked]` for `__rust_probestack`
Let's see if this works now.
Previously this change was in https://github.com/rust-lang/compiler-builtins/pull/897, but we decided to wait until `compiler-builtins` was a subtree (and also `cfg(bootstrap)` is gone now).
r? ``@tgross35`` cc ``@bjorn3``
try-job: `dist-various*`
try-job: `test-various*`
Add central execution context to bootstrap
This PR continues the effort toward command centralization as outlined in https://github.com/rust-lang/rust/issues/126819. It introduces a centralized execution context through which all commands will be executed. Previously, centralization was limited to build methods; this PR extends it to the `config` module and updates the remaining methods accordingly.
Best reviewed commit by commit.
r? ``@Kobzol``
Don't create .msi installer for gnullvm hosts
WIX toolset works only on Windows hosts, but gnullvm doesn't have host toolchain yet. To get out of this loop, we will create a single release without MSI installer.
Split out from: https://github.com/rust-lang/rust/pull/140772
Note the version and PR of removed features when using it
Fixesrust-lang/rust#141619
I added the diagnostic information. Since all the current version information is present, it prints the version information anyway, as shown in tests/ui. And PR will not print if it is None, we can gradually add the PR links.
Split into two commits for easier review.
r? compiler
cc ``@jyn514`` Since you're on vocation in the review list, I can't r? you.
Stabilize keylocker
This PR stabilizes the feature flag `keylocker_x86` (tracking issue rust-lang/rust#134813).
# Public API
The 2 `x86` target features `kl` and `widekl`, and the associated intrinsics in stdarch.
These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 11 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.
Also, these were added way back in LLVM12, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
# Associated PRs
- rust-lang/rust#134814
- rust-lang/stdarch#1706
- rust-lang/rust#136831 (stdarch submodule update)
- rust-lang/stdarch#1795 (stabilizing the runtime detection and intrinsics)
- rust-lang/rust#141964 (stdarch submodule update for the stabilization of the runtime detection and intrinsics)
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.
cc ````@rust-lang/lang````
cc ````@rust-lang/libs-api```` for the intrinsics and runtime detection
I don't think anyone else worked on this feature, so no one else to ping, maybe cc ````@Amanieu.```` I will send the reference pr soon.
Exhaustively handle parsed attributes in CheckAttr
This pr
- Deletes the unused `DiagnosticAttribute ` struct and variant
- Comments the `AttributeKind ` enum
- The match in `CheckAttrVisitor` is now exhaustive for `AttributeKind::Parsed`.
- Moved some checks around after that change
I did *not* thoroughly check that there's no duplicated logic between this pass and the attribute parsing but I think it's OK.
r? ````@jdonszelmann````
Specify the behavior of `file!`
This takes the current behavior of `file!` and documents it so it is safe to make assumptions about.
For example, Cargo could provide a `CARGO_RUSTC_CURRENT_DIR` as a base path for `file!`.
Example use cases
- Being able to look up test assets relative to the current file ([example](b9026bf654/tests/testsuite/cargo_add/add_basic/mod.rs (L34)))
- Inline snapshotting libraries being able to update Rust source code ([example](b9026bf654/tests/testsuite/alt_registry.rs (L36-L45)))
See rust-lang/cargo#3946 for more context.
T-libs-api discussed two solutions in rust-lang/libs-team#478
- `file_absolute!`:
- Has less meaning in other build tools like buck2
- Bakes in the assumption that a full path is available (e.g. with trim-paths)
- Specifying `file!`s behavior (this PR):
- Leaves it to the user to deal with trim-paths
- Even though `file!` is currently unspecified, changing it would likely have too large of an impact on the ecosystem at this time.
A future possibility is that rustc could have a flag that controls modifies the base path used for `file!`.
That seems purely additive with specifying the behavior and we do not want to block on it.
It would also likely be too disruptive for Cargo users (as mentioned). However, we tried to keep this in mind when specifying the behavior.
Update cargo
18 commits in 64a12460708cf146e16cc61f28aba5dc2463bbb4..fc1518ef02b77327d70d4026b95ea719dd9b8c51
2025-05-30 18:25:08 +0000 to 2025-06-06 04:49:44 +0000
- fix: Make UI tests handle hyperlinks consistently (rust-lang/cargo#15640)
- Update "time out" to "timeout" (rust-lang/cargo#15637)
- fix(workspace): reload current manifest path member only (rust-lang/cargo#15633)
- Update dependencies (rust-lang/cargo#15635)
- fix(publish): Don't tell people to ctrl-c without knowing consequences (rust-lang/cargo#15632)
- refactor: clean up `clippy::perf` lint warnings (rust-lang/cargo#15631)
- fix(package): Skip registry check if its not needed (rust-lang/cargo#15629)
- Add --offline for comp (rust-lang/cargo#15623)
- cargo-credential-libsecret: load libsecret only once (rust-lang/cargo#15295)
- test(publish): Improvements in prep for `-Zpackage-workspace` stabilization (rust-lang/cargo#15628)
- fix(package): Allow packaging of self-cycles with -Zpackage-workspace (rust-lang/cargo#15626)
- docs: clarify `--all-features` not available for all commmands (rust-lang/cargo#15572)
- Remove double reference in Shell::print_json (rust-lang/cargo#15460)
- fix(trim-paths): remap all paths to `build.build-dir` (rust-lang/cargo#15614)
- test(trim-paths): enable more tests for windows-msvc (rust-lang/cargo#15621)
- fix(fingerprint): explicit reason rather than "stale; unknown reason" (rust-lang/cargo#15617)
- Fix cargo add overwriting symlinked Cargo.toml files (rust-lang/cargo#15281)
- chore(deps): update alpine docker tag to v3.22 (rust-lang/cargo#15616)
r? ghost
Enable Non-determinism of float operations in Miri and change std tests
Links to [#4208](https://github.com/rust-lang/miri/issues/4208) and [#3555](https://github.com/rust-lang/miri/issues/3555) in Miri.
Non-determinism of floating point operations was disabled in rust-lang/rust#137594 because it breaks the tests and doc-tests in core/coretests and std. This PR enables some of them.
This pr includes the following changes:
- Enables the float non-determinism but with a lower relative error of 4ULP instead of 16ULP
- These operations now have a fixed output based on the C23 standard, except the pow operations, this is tracked in [#4286](https://github.com/rust-lang/miri/issues/4286#issue-3010677983)
- Changes tests that made incorrect assumptions about the operations, not to make that assumption anymore (from `assert_eq!` to `assert_approx_eq!`.
- Changed the doctests of the stdlib of these operations to compare against fixed constants instead of `f*::EPSILON`, which now succeed with Miri and `-Zmiri-many-seeds`
- Added a constant `APPROX_DELTA` in `std/tests/floats/f32.rs` which is used for approximation tests, but with a different value when run in Miri. This is to make these tests succeed.
- Added tests in the float tests of Miri to test the C23 behaviour.
Fixes https://github.com/rust-lang/miri/issues/4208
This takes the current behavior of `file!` and documents it so it is
safe to make assumptions about.
For example, Cargo could provide a `CARGO_RUSTC_CURRENT_DIR` as a base
path for `file!`.
Example use cases
- Being able to look up test assets relative to the current file
([example](b9026bf654/tests/testsuite/cargo_add/add_basic/mod.rs (L34)))
- Inline snapshotting libraries being able to update Rust source code
([example](b9026bf654/tests/testsuite/alt_registry.rs (L36-L45)))
T-libs-api discussed two solutions
- `file_absolute!`:
- Has less meaning in other build tools like buck2
- Bakes in the assumption that a full path is available (e.g. with
trim-paths)
- Specifying `file!`s behavior (this PR):
- Leaves it to the user to deal with trim-paths
- Even though `file!` is currently unspecified, changing it would
likely have too large of an impact on the ecosystem at this time.
A future possibility is that rustc could have a flag that controls
modifies the base path used for `file!`.
That seems purely additive with specifying the behavior and we do not
want to block on it.
It would also likely be too disruptive for Cargo users (as mentioned).
However, we tried to keep this in mind when specifying the behavior.
It's purely internal, and not intended to be a public API, even on
nightly. This stops it showing up and being misleading in rustdoc
search.
It also mirrors the (also internal) `core::slice::sort` module.
Stabilize `sha512`, `sm3` and `sm4` for x86
This PR stabilizes the feature flag `sha512_sm_x86` (tracking issue rust-lang/rust#126624).
# Public API
The 3 `x86` target features `sha512`, `sm3` and `sm4`, and the associated intrinsics in stdarch.
These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 10 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.
Also, these were added in LLVM17, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
# Associated PRs
- rust-lang/rust#126704
- rust-lang/stdarch#1592
- rust-lang/stdarch#1790
- rust-lang/rust#140389 (stdarch submodule update)
- rust-lang/stdarch#1796 (stabilizing the runtime detection and intrinsics)
- rust-lang/rust#141964 (stdarch submodule update for the stabilization of the runtime detection and intrinsics)
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.
cc `@rust-lang/lang`
cc `@rust-lang/libs-api` for the intrinsics and runtime detection
I don't think anyone else worked on this feature, so no one else to ping, maybe cc `@Amanieu.` I will send the reference pr soon.
