Perform InstSimplify before ReferencePropagation.
`InstSimplify` clears CFG caches.
But it currently happens between `ReferencePropagation` and `GVN`, which both use dominators, a quite expensive computation.
r? `@ghost`
PassWrapper: use non-deprecated lookupTarget method
This avoids an extra trip through a triple string by directly passing the Triple, and has been available since LLVM 21. The string overload was deprecated today and throws an error on our CI for HEAD due to -Werror paranoia, so we may as well clean this up now and also skip the conversion on LLVM 21 since we can.
`@rustbot` label llvm-main
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.
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````
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)
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
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
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
`DepNodeColor` tweaks
A follow-up to rust-lang/rust#147293, where I attempted and mostly failed to make things faster again, but I found a few cleanups worth doing.
r? `@saethlin`
rename `select_where_possible` and `select_all_or_error`
r? `@lcnr`
I find that people get confused by what these methods do. The verb "select" is not really that helpful and is just a reference to somewhat of an implementation detail of the trait solvers that doesn't even apply to most obligation kinds.
I went with `try_evaluate_obligations` and `evaluate_obligations_error_on_ambiguity`. This maintains consistency with the new solvers `evalute_goal` entry point. it's unfortunate that we say obligations rather than goals but this maintains consistency with `register_obligation` functions which I think is a good thing. In the long term possibly we rename `Obligation` or `Goal` 🤷♀️
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146865 (kcfi: only reify trait methods when dyn-compatible)
- rust-lang/rust#147205 (Add a new `wasm32-wasip3` target to Rust)
- rust-lang/rust#147322 (cg_llvm: Consistently import `llvm::Type` and `llvm::Value`)
- rust-lang/rust#147398 (Fix; correct placement of type inference error for method calls)
- rust-lang/rust#147410 (Update `S-waiting-on-team` refs to new `S-waiting-on-{team}` labels)
- rust-lang/rust#147422 (collect-license-metadata: Print a diff of the expected output)
- rust-lang/rust#147431 (compiletest: Read the whole test file before parsing directives)
- rust-lang/rust#147433 (Fix doc comment)
Failed merges:
- rust-lang/rust#147390 (Use globals instead of metadata for std::autodiff)
r? `@ghost`
`@rustbot` modify labels: rollup
cg_llvm: Consistently import `llvm::Type` and `llvm::Value`
We already have other modules that import these types and other types from `llvm`, so having the re-exports `type_::Type` and `value::Value` just distracts rust-analyzer and results in messier and less-consistent imports.
No functional change.
Add a new `wasm32-wasip3` target to Rust
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target.
These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
kcfi: only reify trait methods when dyn-compatible
fixes https://github.com/rust-lang/rust/issues/146853
Only generate a `ReifyShim` for trait method calls if the trait is dyn-compatible.
Until now kcfi would generate a `ReifyShim` whenever a trait method was cast to a function pointer. But technically the shim is only needed for dyn-compatible traits (where the method might end up in a vtable).
Up to this point that was only slightly inefficient, but in combination with c-variadic trait methods it is wrong. For c-variadic trait methods the generated shim is incorrect, and that is why c-variadic methods make a trait no longer dyn-compatible: we should simply never generate a `ReifyShim` that is c-variadic.
With this change the documentation on `ReifyReason` is now actually correct:
> If KCFI is enabled, creating a function pointer from a method on a dyn-compatible trait. This includes the case of converting `::call`-like methods on closure-likes to function pointers.
cc ```@maurer``` ```@workingjubilee```
r? ```@rcvalle```
bors