| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
update enzyme submodule
I upstreamed a few of our rust-lang/Enzyme patches, so I could drop them in our fork.
r? compiler
|
|
Prevent ABI changes affect EnzymeAD
This PR handles ABI changes for autodiff input arguments to improve Enzyme compatibility. Fundamentally this adjusts activities when a function argument is lowered as an `ScalarPair`, so there's no mismatch between diff activities and args. Also removes activities corresponding to ZSTs.
fixes: https://github.com/rust-lang/rust/issues/144025
r? `@ZuseZ4`
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146566 (Lint more overlapping assignments in MIR.)
- rust-lang/rust#146645 (Cleanup `FnDecl::inner_full_print`)
- rust-lang/rust#146664 (Clean up `ty::Dynamic`)
- rust-lang/rust#146673 (cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 4))
- rust-lang/rust#146694 (Remove ImplSubject)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove ImplSubject
It only has one usage in rustdoc.
|
|
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 4)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#146631
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
|
|
Clean up `ty::Dynamic`
1. As a follow-up to PR rust-lang/rust#143036, remove `DynKind` entirely.
2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait`
* `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types
* `lint` contained dyn-Trait-specific diagnostics+lints only
|
|
Cleanup `FnDecl::inner_full_print`
`inner_full_print` was pretty hard to follow IMHO.
Hopefully this cleans it up a little bit.
Also, it was checking whether `self.inputs` is empty twice, and then handling an unreachable match arm:
https://github.com/yotamofek/rust/blob/f836ae4e663b6e8938096b8559e094d18361be55/src/librustdoc/html/format.rs#L1368C1-L1368C33
`last_input_index` could only be `None` if the fn has no parameters, in which case the loop body would never run.
r? ``@GuillaumeGomez`` if you have the capacity :)
BTW, can we rename `FnDecl::inputs` to `parameters` or something? And `output` to `return_ty`?
|
|
Lint more overlapping assignments in MIR.
In an effort to make bugs like https://github.com/rust-lang/rust/issues/146383 more easily discovered, this PR extends the "overlapping assignment" MIR lint.
I had to whitelist some rvalues, as they are actually allowed to alias, like `a = a + 1`.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146458 (Add parallel-frontend-threads to bootstrap.toml and enable multi-threaded parallel compilation)
- rust-lang/rust#146485 (Remove unsized arg handling in `ArgAbiBuilderMethods::store_fn_arg` implementations)
- rust-lang/rust#146536 (clean up several trait related UI tests)
- rust-lang/rust#146598 (Make llvm_enzyme a regular cargo feature)
- rust-lang/rust#146647 (Move `#[rustc_coherence_is_core]` to the `crate_level` file)
- rust-lang/rust#146654 (Do not use `git -C dir`)
- rust-lang/rust#146681 (Add space after brace in `Box<[T]>::new_uninit_slice` example)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Add space after brace in `Box<[T]>::new_uninit_slice` example
Trivial cosmetic change.
|
|
Do not use `git -C dir`
Older versions of git (≤ 1.8.5) do not support the `-C dir` global option. Use the `cwd` optional argument when using Python's `subprocess` functionality instead.
Fix rust-lang/rust#142534
|
|
Move `#[rustc_coherence_is_core]` to the `crate_level` file
I implemented this one without realizing it already was since it was (in my opinion) in the wrong file and implemented in a batch of all non-crate-level attributes. This commit just cleans it up slightly and moves it. Should be trivial
r? `@oli-obk`
|
|
Make llvm_enzyme a regular cargo feature
This makes it clearer that it is set by the build system rather than by the rustc that compiles the current rustc. It also avoids bootstrap needing to pass `--check-cfg llvm_enzyme` to rustc.
|
|
clean up several trait related UI tests
Part of rust-lang/rust#133895
Cleaned up several `issue-xxxx` trait related tests from `/tests/ui/issues`, one commit per issue for review. Will squash them once approved.
Related issues:
rust-lang/rust#19479
rust-lang/rust#2284
rust-lang/rust#18088
rust-lang/rust#21950
|
|
Remove unsized arg handling in `ArgAbiBuilderMethods::store_fn_arg` implementations
... since it is unreachable and would ICE anyway.
These branches are unreachable with how `store_fn_arg` is currently used (where it is called, unsized arguments are either: 1. not (yet) supported, or 2. handled differently)[^1], and even if they were reachable, they would ICE anyway, since they call [`OperandValue::store`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#855-861), which calls [`OperandValue::store_with_flags`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#887-926) which [panics on any unsized layout](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#900-903).
Also updates the `bug!` message in `store_arg` to not suggest `store_fn_arg` for unsized args.
[^1]: `store_fn_arg` is only nontrivially[^2] called in `compiler/rustc_codegen_ssa/src/mir/mod.rs` for: Line 428 `extern "rust-call"` tuple (un)splitting, which does not support unsized arguments, Line 496 which is only for sized `PassMode::Indirect` (`meta_attrs: None`) arguments, and Line 521 which is only for non-`PassMode::Indirect` arguments which can never be unsized.
[^2]: `<Bx as ArgAbiBuilderMethods>::store_fn_arg` is what is actually called, but codegen_llvm and codegen_gcc's builders both delegate to their own `codegen_crate::ArgAbiExt::store_fn_arg`, which contain the actual implementations that are changed in this PR.
|
|
Add parallel-frontend-threads to bootstrap.toml and enable multi-threaded parallel compilation
Add the option to use the parallel compiler when building Rust code in bootstrap.
|
|
Fix `env::ArgsOs` for zkVM
The zkVM implementation of `env::ArgsOs` incorrectly reports the full length even after having iterated. Instead, use a range approach which works out to be simpler. Also, implement more iterator methods like the other platforms in #139847.
cc `@flaub` `@jbruestle` `@SchmErik`
|
|
|
|
|
|
|
|
|
|
interpret: copy_provenance: avoid large intermediate buffer for large repeat counts
Copying provenance worked in this odd way where the "preparation" phase (which is supposed to just extract the necessary information from the source range) already did all the work of repeating the result N times for the target range. This was needed to use the existing `insert_presorted` function on `SortedMap`.
This PR generalizes `insert_presorted` so that we can avoid this odd structure on copy-provenance, and maybe even improve performance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Enable DestinationPropagation by default
This PR proposes to perform destination propagation on MIR. Most of the pass was fully rewritten by `@JakobDegen` in rust-lang/rust#96451.
This pass is quite heavy, as it needs to perform and save the results of a full liveness dataflow analysis. This accounts for ~50% of the pass' runtime.
Perf sees a few decent savings in later llvm passes, but also sizeable régressions when there are no savings to balance this pass' runtime.
|
|
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#142807 (libtest: expose --fail-fast as an unstable command-line option)
- rust-lang/rust#144871 (Stabilize `btree_entry_insert` feature)
- rust-lang/rust#145071 (Update the minimum external LLVM to 20)
- rust-lang/rust#145181 (remove FIXME block from `has_significant_drop`, it never encounters inference variables)
- rust-lang/rust#145660 (initial implementation of the darwin_objc unstable feature)
- rust-lang/rust#145838 (don't apply temporary lifetime extension rules to non-extended `super let`)
- rust-lang/rust#146259 (Suggest removing Box::new instead of unboxing it)
- rust-lang/rust#146410 (Iterator repeat: no infinite loop for `last` and `count`)
- rust-lang/rust#146460 (Add tidy readme)
- rust-lang/rust#146552 (StateTransform: Do not renumber resume local.)
- rust-lang/rust#146564 (Remove Rvalue::Len again.)
- rust-lang/rust#146581 (Detect attempt to use var-args in closure)
- rust-lang/rust#146588 (tests/run-make: Update list of statically linked musl targets)
- rust-lang/rust#146631 (cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 3))
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 3)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#136375
- Follow-up to rust-lang/rust#136632
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
This PR migrates all of the bindings that were touched by rust-lang/rust#136632, plus `LLVMDIBuilderCreateStructType`.
|
|
tests/run-make: Update list of statically linked musl targets
All of the tier 3 targets in the list now link dynamically by default (except `mips64el-unknown-linux-muslabi64`, I apparently overlooked that one in my PR that changed this).
Adjust the list of targets expected to link statically accordingly.
See also https://github.com/rust-lang/rust/pull/144410, which changed these targets.
Target by target:
- `mips64-unknown-linux-musl`: this target does not exist AFAICT
- `mips64-unknown-linux-muslabi64`: updated in the linked PR
- `powerpc-unknown-linux-musl`: updated in the linked PR
- `powerpc-unknown-linux-muslspe`: updated in the linked PR
- `powerpc64-unknown-linux-musl`: updated in the linked PR
- `riscv32gc-unknown-linux-musl`: updated in the linked PR
- `s390x-unknown-linux-musl`: updated in the linked PR
- `thumbv7neon-unknown-linux-musleabihf`: updated in the linked PR
|
|
Detect attempt to use var-args in closure
```
error: unexpected `...`
--> $DIR/no-closure.rs:11:14
|
LL | let f = |...| {};
| ^^^ not a valid pattern
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
error: unexpected `...`
--> $DIR/no-closure.rs:16:17
|
LL | let f = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
Fix rust-lang/rust#146489, when trying to use c-style var-args in a closure. We emit a more targeted message. We also silence inference errors when the pattern is `PatKind::Err`.
|
|
Remove Rvalue::Len again.
Now that we have `RawPtrKind::FakeForPtrMetadata`, we can reimplement `Rvalue::Len` using `PtrMetadata(&raw const (fake) place)`.
r? ``@scottmcm``
|
|
StateTransform: Do not renumber resume local.
MIR parameters are not explicitly assigned-to when entering the MIR body. If we want to save their values inside the coroutine state, we need to do so explicitly.
This was done by renaming the `_2` local, and introducing an explicit assignment pre-transform. This particular trick confuses me.
This version makes explicit that we are assigning parameters to saved locals.
r? ``@dingxiangfei2009``
|
|
Add tidy readme
This PR adds a Readme to `src/tools/tidy`. Basically just explains how `tidy` works and covers all of tidy's checks, directives, and how to use tidy. I tried to add a bit more detail on some of the options like `--extra-checks` and the style directives that aren't really documented well elsewhere.
Planning to link to this in the dev guide.
Closes: rust-lang/rust#129368
|
|
Iterator repeat: no infinite loop for `last` and `count`
This removes two cases of infinite looping from [`Repeat`](https://doc.rust-lang.org/nightly/std/iter/struct.Repeat.html):
- [`last`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.last): By viewing the iterator as returning None after [omega](https://en.wikipedia.org/wiki/Ordinal_number) calls to `next`, this method can simply return the repeated element.
- [`count`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.count): From its docs: """The method does no guarding against overflows, so counting elements of an iterator with more than [usize::MAX](https://doc.rust-lang.org/nightly/std/primitive.usize.html#associatedconstant.MAX) elements either produces the wrong result or panics. If overflow checks are enabled, a panic is guaranteed.""", so a panic'ing impl is allowed by the docs, and is more honest than an infinite loop.
|
|
Suggest removing Box::new instead of unboxing it
|
|
don't apply temporary lifetime extension rules to non-extended `super let`
Reference PR: rust-lang/reference#1980
This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in https://github.com/rust-lang/rust/issues/145784#issuecomment-3218658335, making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).
Closes rust-lang/rust#145784
This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.
Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated
Tracking issue for `super let`: rust-lang/rust#139076
|
|
initial implementation of the darwin_objc unstable feature
Tracking issue: https://github.com/rust-lang/rust/issues/145496
This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.
r? ```@tmandry```
try-job: `*apple*`
try-job: `x86_64-gnu-nopt`
|
|
remove FIXME block from `has_significant_drop`, it never encounters inference variables
The `FIXME` block in `Ty::has_significant_drop` is outdated as related queries can now handle type inference.
https://github.com/rust-lang/rust/blob/321a89bec57b8ca723d1af8f784490b950458c6a/compiler/rustc_middle/src/ty/util.rs#L1378-L1389
Closes rust-lang/rust#86868 (other places mentioned in the issue have been resolved, or moved to other issues)
r? types
|
|
Update the minimum external LLVM to 20
With this change, we'll have stable support for LLVM 20 and 21.
For reference, the previous increase to LLVM 19 was rust-lang/rust#139275.
cc ```@rust-lang/wg-llvm```
r? nikic
|
|
Stabilize `btree_entry_insert` feature
This stabilises `btree_map::VacantEntry::insert_entry` and `btree_map::Entry::insert_entry`, following the FCP in [tracking issue](https://github.com/rust-lang/rust/issues/65225).
New stable API:
```rust
impl<'a, K: Ord, V, A: Allocator + Clone> Entry<'a, K, V, A> {
pub fn insert_entry(self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
impl<'a, K: Ord, V, A: Allocator + Clone> VacantEntry<'a, K, V, A> {
pub fn insert_entry(mut self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
```
(FCP ended almost a year ago, so if it's needed for process we could rerun it)
Closes: https://github.com/rust-lang/rust/issues/65225
|
|
libtest: expose --fail-fast as an unstable command-line option
This exposes the `fail_fast` option added in rust-lang/rust#105153 on the test harness command line, so that workflows that only want to know if any test fails can find out without waiting for everything to run. For example, cargo-mutants just needs to know if any tests fails. It only works with `-Zunstable-options`.
Tracking issue: rust-lang/rust#142859
|
