Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#146568 (Port the implemention of SIMD intrinsics from Miri to const-eval)
- rust-lang/rust#147373 (give a better example why `std` modules named like primitives are needed)
- rust-lang/rust#147419 (bootstrap: add `Builder::rustc_cmd` that includes the lib path)
- rust-lang/rust#147420 (Add diagnostic items for `pub mod consts` of FP types)
- rust-lang/rust#147457 (specialize slice::fill to use memset when possible)
- rust-lang/rust#147467 (Fix double warnings on `#[no_mangle]`)
- rust-lang/rust#147470 (Clarify how to remediate the panic_immediate_abort error)
- rust-lang/rust#147480 (Do not invalidate CFG caches in CtfeLimit.)
- rust-lang/rust#147481 (format: some small cleanup)
- rust-lang/rust#147488 (refactor: Remove `LLVMRustInsertPrivateGlobal` and `define_private_global`)
- rust-lang/rust#147489 (Prefer to use repeat_n over repeat().take())
- rust-lang/rust#147506 (compiletest: Isolate public APIs and minimize public surface area)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Isolate public APIs and minimize public surface area
As part of my ongoing efforts to improve directive parsing, I would like to be able to make internal changes without worrying about whether they're going to break the rustdoc-gui-test tool. That tool currently uses compiletest as a dependency to help with directive parsing.
This PR therefore isolates all of compiletest's public APIs into two dedicated modules, one used by rustdoc-gui-test, and one used by the compiletest binary in `compiletest/src/bin/main.rs`.
All other modules (and crate-root items) are then made non-`pub` to achieve the API isolation. Doing so reveals some unused items, which have been removed.
(To reduce the amount of immediate textual churn, this PR does not comprehensively replace `pub` with `pub(crate)` throughout the whole crate; that could be done in a follow-up PR.)
---
Ideally, rustdoc-gui-test would not depend on compiletest at all, but properly fixing that is out of scope for this PR.
- rust-lang/rust#143827
r? jieyouxu
Prefer to use repeat_n over repeat().take()
More from https://github.com/rust-lang/rust/pull/147464, but batch processed with `ast-grep` to find and replace.
second commit add notes for library: affaf532f9
r? ``@RalfJung``
refactor: Remove `LLVMRustInsertPrivateGlobal` and `define_private_global`
Since it can easily be implemented using the existing LLVM C API in
terms of `LLVMAddGlobal` and `LLVMSetLinkage` and `define_private_global`
was only used in one place.
Work towards https://github.com/rust-lang/rust/issues/46437
Do not invalidate CFG caches in CtfeLimit.
This does not matter much, as no optimization pass runs after `CtfeLimit`, but I still find the code cleaner.
Clarify how to remediate the panic_immediate_abort error
Users who build `core` for the sole purpose of enabling `panic_immediate_abort` might expect "`panic_immediate_abort` is now a real panic strategy" to mean that setting `panic = "immediate-abort"` in `Cargo.toml` or `-Cpanic=immediate-abort` in `RUSTFLAGS` to be sufficient for migration. But this is not the case, `core` still needs to be built for those changes to take effect.
See https://github.com/rust-lang/rust/issues/146974 for additional context.
See https://github.com/rust-lang/rust/issues/147286 and https://github.com/rust-lang/cargo/issues/16042 for the revelant tracking issues.
Fix double warnings on `#[no_mangle]`
Fixes 2 out of 3 cases in https://github.com/rust-lang/rust/issues/147417
The fix on closures removes the old error and marks closures as an error target.
The fix on consts adds `AllowSilent` to to ignore a target, and uses the old error because that one has a nice suggestion.
r? ````@jdonszelmann````
bootstrap: add `Builder::rustc_cmd` that includes the lib path
When building with `rust.rpath = false`, every `rustc` invocation needs
to include the library path as well. I particularly ran into this in
`generate_target_spec_json_schema` when testing 1.91-beta in Fedora,
where we do disable rpath for our system builds. The new helper function
will hopefully encourage the right thing going forward.
give a better example why `std` modules named like primitives are needed
A small update to the `std` `lib.rs` introduction to replace mentions of `std::i32` (never needed) with `std::char` (sometimes needed).
Related to rust-lang/rust#146882.
Port the implemention of SIMD intrinsics from Miri to const-eval
Ported the implementation of most SIMD intrinsics from Miri to rustc_const_eval. Remaining are
- Math functions (as per `@RalfJung's` suggestions)
- FMA (non-deterministic)
- Funnel Shifts (not implemented in Miri yet)
- Unordered reduction intrinsics (not implemented in Miri yet)
All APIs used from outside the compiletest library crate have been isolated to
the `cli` and `rustdoc_gui_test` modules, so no other items need to be publicly
exported.
Refactor AddCallGuards in two loops.
This PR splits the pass into an analysis loop and a change loop. This allows to avoid invalidating CFG caches if there are no changes to be performed.
r? `@ghost` for perf
Since it can easily be implemented using the existing LLVM C API in
terms of `LLVMAddGlobal` and `LLVMSetLinkage` and `define_private_global`
was only used in one place.
GVN: Evaluate constants lazily.
GVN currently evaluates constants eagerly. This is not necessary. This PR makes constant evaluation on-demand to avoid unnecessary work.
r? `@ghost` for perf
refactor: replace `LLVMRustAtomicLoad/Store` with LLVM built-in functions
This simplifies the code and reduces the burden of maintaining our own wrappers.
Work towards https://github.com/rust-lang/rust/issues/46437
some more `proc_macro` cleanups
Several smaller cleanups to `proc_macro`. Commits 1 and 3 seem pretty trivial to me, commit 2 might be worth it or not.
Followup to rust-lang/rust#147166.
clarify wording of match ergonomics diagnostics (`rust_2024_incompatible_pat` lint and error)
Partially addresses rust-lang/rust#143557:
- Uses different wording than the Edition Guide chapter, to hopefully stand alone a bit better. Instead of referring to the "default binding mode", it now talks about what can't be written "within elided reference patterns". I ended up going with "elided" instead of "implicit" in hope that it reads bit less like it should behave the same as an explicit reference pattern, but I'm not totally happy with that wording.
- The explanatory note still points to where the default binding mode was introduced, but only refers to its effect, not what we call it. How that relates to the rest of the diagnostic may still be a bit of a puzzle, but hopefully it isn't too much of one? It also doesn't make sense anymore for the case of `&` written under a by-ref binding mode, so I've left the note out in that case (but kept the label). It's more cramped, but talking about binding modes would feel like a non-sequitur for the error about `&` patterns without further explanation.
- Links to the stable version of the Edition Guide instead of the nightly version. It looks like almost every link to the Edition Guide in diagnostics is to the nightly version, presumably for the same reason as here: the diagnostics were added before the new Edition was stabilized, then never updated. I'll make a separate PR to clean up the others.
This only changes the diagnostic messages, not the code suggestion or the Edition Guide.
r? `@Nadrieril` or reassign
Users who build `core` for the sole purpose of enabling `panic_immediate_abort` might expect
"`panic_immediate_abort` is now a real panic strategy" to mean that setting `panic =
"immediate-abort"` in `Cargo.toml` or `-Cpanic=immediate-abort` in `RUSTFLAGS` to be sufficient for
migration. But this is not the case, `core` still needs to be built for those changes to take
effect.
See https://github.com/rust-lang/rust/issues/146974 for additional context.
sort attribute targets for more consistent error messages
In this PR I noticed that we don't sort attribute targets, so a rather trivial change to the source changed the ordering in an error message even though its meaning stayed the same.
See: https://github.com/rust-lang/rust/pull/147418#discussion_r2410852750
I think sorting might be a good thing to do in general. I also prefer it when reading error messages. Quite a few tests changed, but not in meaning, only sorting order obviously.
r? `@jieyouxu`
Use globals instead of metadata for std::autodiff
LLVM's Metadata is quite fragile. In debug builds we use incremental compilation, which caused the metadata to be dropped. With this change we use named globals instead of metadata to instruct Enzyme how to differentiate functions.
Globals are proper llvm values and thus can't be dropped. Also added an incremental/dbg test which now passes, to unblock the EnzymeAD CI which wants to run Rust autodiff tests.
r? compiler
