Autodiff Upstreaming - enzyme backend
Tracking issue: https://github.com/rust-lang/rust/issues/124509
Part of https://github.com/rust-lang/rust/pull/129175
This PR should allow building Enzyme from source on Tier 1 targets (when also building LLVM), except MSVC.
It's only a small fraction (~200 lines) of the whole upstream PR, but due to bootstrapping and the number of configurations in which rustc can be build I assume that this will be the hardest to merge, so I'm starting with it.
Happy to hear what changes are required to be able to upstream this code.
**Content:**
It contains a new configure flag `--enable-llvm-enzyme`, and will build the new Enzyme submodule when it is set.
**Discussion:**
Apparently Rust CI isn't able to clone repositories outside the rust-lang org? At least I'm seeing this error in CI:
```
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
Does that mean we would need to mirror github.com/EnzymeAD/Enzyme in rust-lang, until LLVM upgrades Enzyme from an Incubator project to something that ships as part of the monorepo?
Tracking:
- https://github.com/rust-lang/rust/issues/124509
coverage: Count await when the Future is immediately ready
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.
By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.
I added a test to ensure the fix works in simple cases, but the heuristic of picking only the first await-related covspan might be unreliable. I plan on testing more thoroughly with a real codebase over the next couple of weeks.
closes#98712
Remove wasm32-wasip2's tier 2 status from release notes
It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for `wasm32-wasip2` required two PRs:
* #126967 - this made it into Rust 1.81
* #127867 - this didn't make the cut and is in Rust 1.82 instead
This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.
Make `Ty::boxed_ty` return an `Option`
Looks like a good place to use Rust's type system.
---
Most of 4ac7bcbaad/compiler/rustc_middle/src/ty/sty.rs (L971-L1963) looks like it could be moved to `TyKind` (then I guess `Ty` should be made to deref to `TyKind`).
Inaccurate `{Path,OsStr}::to_string_lossy()` documentation
The documentation of `Path::to_string_lossy()` and `OsStr::to_string_lossy()` says the following:
> Any non-Unicode sequences are replaced with `U+FFFD REPLACEMENT CHARACTER`
which didn't immediately make sense to me. ("non-Unicode sequences"?)
Since both `to_string_lossy` functions eventually become just a call to `String::from_utf8_lossy`, I believe the documentation meant to say:
> Any *non-UTF-8* sequences are replaced with `U+FFFD REPLACEMENT CHARACTER`
This PR corrects this mistake in the documentation.
For the record, a similar quote can be found in the documentation of `String::from_utf8_lossy`:
> ... During this conversion, `from_utf8_lossy()` will replace any invalid UTF-8 sequences with `U+FFFD REPLACEMENT CHARACTER`, ...
Make `./x.py <cmd> compiler/<crate>` aware of the crate's features
Does not fix https://github.com/rust-lang/rust/issues/129727 on its own as the way the parallel-compiler cfg and feature flags are setup being generally incompatible with `resolver = 2` but it progresses on the issue. But this should in theory allow compiler crates to work that do not depend on the parallel compiler stuff (so some leaf crates).
Check WF of source type's signature on fn pointer cast
This PR patches the implied bounds holes slightly for #129005, #25860.
Like most implied bounds related unsoundness fixes, this isn't complete w.r.t. higher-ranked function signatures, but I believe it implements a pretty good heuristic for now.
### What does this do?
This PR makes a partial patch for a soundness hole in a `FnDef` -> `FnPtr` "reifying" pointer cast where we were never checking that the signature we are casting *from* is actually well-formed. Because of this, and because `FnDef` doesn't require its signature to be well-formed (just its predicates must hold), we are essentially allowed to "cast away" implied bounds that are assumed within the body of the `FnDef`:
```
fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }
fn bad<'short, T>(x: &'short T) -> &'static T {
let f: fn(_, &'short T) -> &'static T = foo;
f(&&(), x)
}
```
In this example, subtyping ends up casting the `_` type (which should be `&'static &'short ()`) to some other type that no longer serves as a "witness" to the lifetime relationship `'short: 'static` which would otherwise be required for this call to be WF. This happens regardless of if `foo`'s lifetimes are early- or late-bound.
This PR implements two checks:
1. We check that the signature of the `FnDef` is well-formed *before* casting it. This ensures that there is at least one point in the MIR where we ensure that the `FnDef`'s implied bounds are actually satisfied by the caller.
2. Implements a special case where if we're casting from a higher-ranked `FnDef` to a non-higher-ranked, we instantiate the binder of the `FnDef` with *infer vars* and ensure that it is a supertype of the target of the cast.
The (2.) is necessary to validate that these pointer casts are valid for higher-ranked `FnDef`. Otherwise, the example above would still pass even if `help`'s `'a` lifetime were late-bound.
### Further work
The WF checks for function calls are scattered all over the MIR. We check the WF of args in call terminators, we check the WF of `FnDef` when we create a `const` operand referencing it, and we check the WF of the return type in #115538, to name a few.
One way to make this a bit cleaner is to simply extend #115538 to always check that the signature is WF for `FnDef` types. I may do this as a follow-up, but I wanted to keep this simple since this leads to some pretty bad NLL diagnostics regressions, and AFAICT this solution is *complete enough*.
### Crater triage
Done here: https://github.com/rust-lang/rust/pull/129021#issuecomment-2297702647
r? lcnr
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.
By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. A future commit will
fix this and update the test to reflect the new behavior.
Don't emit `expect`/`assume` in opt-level=0
LLVM does not make use of expect/assume calls in `opt-level=0`, so we can simplify IR by not emitting them in this case.
The developer experience for panics is to provide the backtrace and
exit the program. When running under debugger, that might be improved
by breaking into the debugger once the code panics thus enabling
the developer to examine the program state at the exact time when
the code panicked.
Let the developer catch the panic in the debugger if it is attached.
If the debugger is not attached, nothing changes. Providing this feature
inside the standard library facilitates better debugging experience.
Validated under Windows, Linux, macOS 14.6, and FreeBSD 13.3..14.1.
Rollup of 8 pull requests
Successful merges:
- #128820 (fix: get llvm type of global val)
- #129028 (`impl_trait_overcaptures`: Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime)
- #129471 ([rustdoc] Sort impl associated items by kinds and then by appearance)
- #129706 (Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir)
- #129720 (Simplify DestProp memory management)
- #129796 (Unify scraped examples with other code examples)
- #129938 (Elaborate on deriving vs implementing `Copy`)
- #129973 (run_make_support: rename `Command::stdin` to `stdin_buf` and add `std{in,out,err}` config helpers)
r? `@ghost`
`@rustbot` modify labels: rollup
forward linker option to lint-docs
This fixes an error found when building the doc for a cross-built toolchain.
```
warning: the code example in lint `unstable_syntax_pre_expansion` in /buildroots/chenx97/rustc-1.80.1-src/compiler/rustc_lint_defs/src/builtin.rs failed to generate the expected output: did not find lint `unstable_syntax_p
re_expansion` in output of example, got:
error: linking with `cc` failed: exit status: 1
...
```
Closes: #129956
copy rustc rustlib artifacts from ci-rustc
We recently (since https://github.com/rust-lang/rust/pull/129311) had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast") when building tools that rely on rustc. This patch fixes that by copying those files as required.
r? Kobzol
Blocker for https://github.com/rust-lang/rust/pull/122709
explain why Rvalue::Len still exists
I just spent a bit of time trying to remove this until I realized why that's non-trivial. Let's document that for the next person. :)
bootstrap: Try to track down why `initial_libdir` sometimes fails
When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this:
```text
thread 'main' panicked at src/lib.rs:341:14:
called `Result::unwrap()` on an `Err` value: StripPrefixError(())
```
It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs.
Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have.
So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
fix ICE when `asm_const` and `const_refs_to_static` are combined
fixes https://github.com/rust-lang/rust/issues/129462fixes#126896fixes#124164
I think this is a case that was missed in the fix for https://github.com/rust-lang/rust/pull/125558, which inserts a type error in the case of an invalid (that is, non-integer) type being passed to an asm `const` operand.
I'm not 100% sure that `span_mirbug_and_err` is the right macro here, but it is used earlier with `builtin_deref` and seems to do the trick.
r? ``@lcnr``
Add an internal lint that warns when accessing untracked data
Some methods access data that is not tracked by the query system and should be used with caution. As suggested in https://github.com/rust-lang/rust/pull/128815#issuecomment-2275488683, in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions.
I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough.
r? ``@oli-obk``
It turns out the stars did not actually align for this to get released
in Rust 1.81 alas. Full tier 2 status for `wasm32-wasip2` required two
PRs:
* #126967 - this made it into Rust 1.81
* #127867 - this didn't make the cut and is in Rust 1.82 instead
This wasn't caught until just after today's release so the plan is to
remove the release notes for 1.81 and coordinate to instead add these as
release notes to 1.82.
run_make_support: rename `Command::stdin` to `stdin_buf` and add `std{in,out,err}` config helpers
Previously `Command::stdin` was actually just a stdin buffer helper, but
this is different from `std::process::Command::stdin`. This is
needlessly confusing, and blocks support to add `std{in,out,err}` config
helpers that tests may want to use to e.g. redirect to `/dev/ptmx`.
Elaborate on deriving vs implementing `Copy`
I was reading this documentation and this wasn't immediately clear to me.
In my mind, it seemed obvious that a type can only claim to be `Copy` if the bits it is storing can be `Copy`, and in the case of a generic struct that can only be the case if `T: Copy`. So the bound added by the derive seemed necessary at all times, and I thought what the documentation was trying to say is that the custom implementation allows you to add _additional bounds_.
Of course what it was actually trying to point out is that just because you have a generic parameter `T`, it doesn't necessarily mean you are storing the bits of `T`. And if you aren't, it may be the case that your own bits can be copied regardless of whether the bits of `T` can be safely copied.
Thought it may be worth elaborating to make that a bit more clear. Haven't tested/didn't try to figure out how to render this locally. Mainly not sure if the `PhantomData` back link is going to just work or need some extra stuff, but I figured someone else probably could just tell.
Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir
First, we add a missing match for `DefKind::SyntheticCoroutineBody` in `dump_mir`. Fixes#129703. The second commit (directly below) serves as a test.
Second, we reorder the `dump_mir` in `coroutine_by_move_body_def_id` to be *after* we adjust the body source, and change the disambiguator so it reads more like any other MIR body. This also serves as a test for the ICE, since we're dumping the MIR of a body with `DefKind::SyntheticCoroutineBody`.
Third, we change the parenting of the synthetic MIR body to have the *coroutine-closure* (i.e. async closure) as its parent, so we don't have long strings of `{closure#0}-{closure#0}-{closure#0}`.
try-job: test-various
[rustdoc] Sort impl associated items by kinds and then by appearance
Following [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.22Freeze.22.20order.20of.20items.20in.20.28trait.29.20impls.3F), I implemented it.
This brings the following change: impl associated items will now be grouped by kind and will now be first sorted by kind and then by the order they are declared in the source code (like currently).
The kinds are sorted in the following order:
1. Constants
2. Types
3. Functions
The reason behind this order is that associated constants can be used in associated types (like length in arrays) and both associated types and associated constants can be used in associated functions. So if an associated item from the same impl is used, its definition will always be above where it's being used.
cc ``@camelid``
r? ``@notriddle``
`impl_trait_overcaptures`: Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime
**NOTE:** Review only the first commit carefully. The second one is just moving stuff around, so you can turn whitespace off for that one.
This PR relaxes the `impl_trait_overcaptures` lint to not fire in cases like:
```rust
struct Ctxt<'tcx>(&'tcx ());
impl<'tcx> Ctxt<'tcx> {
fn compute(&self) -> impl Sized + '_ { }
}
```
Specifically, the lint will not fire if **all** overcaptured regions (i.e. those which will be captured in edition 2024, which are not captured today) **satisfy**:
* The region is contravariant (or bivariant) in the function signature
* The region outlives some other region which is captured by the opaque
### The idea behind this
Why is this OK? My reasoning is that since the region is contravariant in the function signature, we know that it can be shortened arbitrarily at the call site. And specifically, we know it can be shortened to be equal to one of the regions that it outlives -- that's why we need to prove that it outlives some other region that *is* captured.
We could technically relax this further, but there would be (IMO somewhat easy) cases to make this a false negative in real code. For example, if the region is invariant, then we can hit issues like:
```rust
struct Ctxt<'tcx>(&'tcx mut &'tcx mut ());
impl<'tcx> Ctxt<'tcx> {
fn compute(&self) -> impl Sized + use<'_, 'tcx> { }
// We use `use<'_, 'tcx>` to show what happens in edition 2024
}
fn test<'a, 'b>(x: &'a Ctxt<'b>, y: &'a Ctxt<'a>) {
let results = [x.compute(), y.compute()];
//~^ ERROR lifetime may not live long enough
// Since both opaques now capture `'tcx`, this enforces that `'a == 'b`.
}
```
### Is this actually totally fine?
There's one case where users might still hit issues, and it's if we turbofish lifetimes directly:
```rust
struct Ctxt<'tcx>(&'tcx ());
impl<'tcx> Ctxt<'tcx> {
fn compute(&self) -> impl Sized + use<'_, 'tcx> { }
}
fn test<'a, 'b>(x: &'a Ctxt<'b>, y: &'a Ctxt<'a>) {
let results = [Ctxt::<'b>::compute(x), Ctxt::<'a>::compute(y)];
//~^ ERROR lifetime may not live long enough
// Since both opaques now capture `'tcx`, this enforces that `'a == 'b`.
// Note that we don't shorten `'b` to `'a` since we turbofished it.
}
```
### Well... we should still warn?
I kinda don't care about this case, though I guess we could possibly downgrade the lint to something like `IMPL_TRAIT_OVERCAPTURES_STRICT` instead of suppressing it altogether. Thoughts? If we were to do this, then I'd probably also opt to include the invariant case in `IMPL_TRAIT_OVERCAPTURES_STRICT` and move it out of `IMPL_TRAIT_OVERCAPTURES`.
