2025 03 29 add autodiff inline #3
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Shourya742
force-pushed
the
2025-03-29-add-autodiff-inline
branch
2 times, most recently
from
287c6db to
5fddbe3
Compare
Shourya742
force-pushed
the
2025-03-29-add-autodiff-inline
branch
4 times, most recently
from
ce3e200 to
4a1b3b1
Compare
…s, r=Kobzol support config extensions _Copied from the `rustc-dev-guide` addition:_ >When working on different tasks, you might need to switch between different bootstrap >configurations. >Sometimes you may want to keep an old configuration for future use. But saving raw config >values in >random files and manually copying and pasting them can quickly become messy, especially if >you have a >long history of different configurations. > >To simplify managing multiple configurations, you can create config extensions. > >For example, you can create a simple config file named `cross.toml`: > >```toml >[build] >build = "x86_64-unknown-linux-gnu" >host = ["i686-unknown-linux-gnu"] >target = ["i686-unknown-linux-gnu"] > > >[llvm] >download-ci-llvm = false > >[target.x86_64-unknown-linux-gnu] >llvm-config = "/path/to/llvm-19/bin/llvm-config" >``` > >Then, include this in your `bootstrap.toml`: > >```toml >include = ["cross.toml"] >``` > >You can also include extensions within extensions recursively. > >**Note:** In the `include` field, the overriding logic follows a right-to-left order. For example, in `include = ["a.toml", "b.toml"]`, extension `b.toml` overrides `a.toml`. Also, parent extensions always overrides the inner ones. try-job: x86_64-mingw-2
Rewrite on_unimplemented format string parser.
This PR rewrites the format string parser for `rustc_on_unimplemented` and `diagnostic::on_unimplemented`. I plan on moving this code (and more) into the new attribute parsing system soon and wanted to PR it separately.
This PR introduces some minor differences though:
- `rustc_on_unimplemented` on trait *implementations* is no longer checked/used - this is actually never used (outside of some tests) so I plan on removing it in the future.
- for `rustc_on_unimplemented`, it introduces the `{This}` argument in favor of `{ThisTraitname}` (to be removed later). It'll be easier to parse.
- for `rustc_on_unimplemented`, `Self` can now consistently be used as a filter, rather than just `_Self`. It used to not match correctly on for example `Self = "[{integer}]"`
- Some error messages now have better spans.
Fixes rust-lang#130627
…ttribute, r=tgross35,traviscross Make `#[naked]` an unsafe attribute tracking issue: rust-lang#138997 Per rust-lang#134213 (comment), the `#[naked]` attribute is now an unsafe attribute (in any edition). This can only be merged when the above PRs are merged, I'd just like to see if there are any CI surprises here, and maybe there is early review feedback too. r? ``@traviscross``
Don't assemble non-env/bound candidates if projection is rigid Putting this up for an initial review, it's still missing comments, clean-up, and possibly a tweak to deal with ambiguities in the `BestObligation` folder. This PR fixes rust-lang/trait-system-refactor-initiative#173. Specifically, we're creating an unnecessary query cycle in normalization by assembling an *impl candidate* even if we know later on during `merge_candidates` that we'll be filtering out that impl candidate. This PR adjusts the `merge_candidates` to assemble *only* env/bound candidates if we have `TraitGoalProvenVia::ParamEnv | TraitGoalProvenVia::AliasBound`. I'll leave some thoughts/comments in the code. r? lcnr
Don't canonicalize crate paths When printing paths in diagnostic we should favour printing the paths that were passed in rather than resolving all symlinks. This PR changes the form of the crate path but it should only really affect diagnostics as filesystem functions won't care which path is used. The uncanonicalized path was already used as a fallback for when canonicalization failed. This is a partial alternative to rust-lang#139823.
…=joboet Move `pal::env` to `std::sys::env_consts` Combine the `std::env::consts` platform implementations as a single file. Use the Unix file as the base, since it has 28 entries, and fold the 8 singleton platforms into it. The Unix file was roughly grouped into Linux, Apple, BSD, and everything else, roughly in alphabetical order. Alphabetically order them to make it easier to maintain and discard the Unix-specific groups to generalize it to all platforms. I'd prefer to have no fallback implementation, as I consider it a bug; however TEEOS, Trusty, and Xous have no definitions here. Since they otherwise have `pal` abstractions, that indicates that there are several platforms without `pal` abstractions which are also missing here. To support unsupported, create a little macro to handle the fallback case and not introduce ordering between the `cfg`s like `cfg_if!`. I've named the module `std::sys::env_consts`, because they are used in `std::env::consts` and I intend to use the name `std::sys::env` for the combination of `Args` and `Vars`. cc `@joboet` `@ChrisDenton` Tracked in rust-lang#117276.
Add citool command for generating a test dashboard This PR implements an initial version of a test suite dashboard, which shows which tests were executed on CI and which tests were ignored. This was discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202025-04-11.20Dealing.20with.20disabled.20tests/with/512799036). The dashboard is still quite bare-bones, but I think that it could already be useful. The next step is to create a job index, similarly to the post-merge report, and link from the individual tests to the job that executed them. You can try it locally like this: ```bash $ cargo run --manifest-path src/ci/citool/Cargo.toml --release \ -- test-dashboard 38c560a --output-dir dashboard ``` and then open `dashboard/index.html` in a web browser. CC ````@wesleywiser```` r? ````@jieyouxu````
… r=jieyouxu Clean UI tests 4 of n Cleaned up some tests that have `issue` in the title. I kept the commits to be one per "`issue`" cleanup/rename to make it easier to check. I can rebase to one commit once the changes are approved. Related Issues: rust-lang#73494 rust-lang#133895 r? jieyouxu
…rn-cleaning error-pattern directive section cleaning
…enton Rollup of 8 pull requests Successful merges: - rust-lang#137454 (not lint break with label and unsafe block) - rust-lang#139297 (Deduplicate & clean up Nix shell) - rust-lang#139535 (Implement `Default` for raw pointers) - rust-lang#139919 (Make rustdoc JSON Span column 1-based, just like line numbers) - rust-lang#139922 (fix incorrect type in cstr `to_string_lossy()` docs) - rust-lang#140007 (Disable has_thread_local on i686-win7-windows-msvc) - rust-lang#140016 (std: Use fstatat() on illumos) - rust-lang#140025 (Re-remove `AdtFlags::IS_ANONYMOUS`) r? `@ghost` `@rustbot` modify labels: rollup
skip-checks: true
Shourya742
force-pushed
the
2025-03-29-add-autodiff-inline
branch
from
e1266af to
752ebf9
Compare
This updates the exploit mitigations chapter in the rustc book to use the footnote feature of mdbook instead of manually implementing footnotes with HTML.
…itchint, r=saethlin
Do not remove trivial `SwitchInt` in analysis MIR
This PR ensures that we don't prematurely remove trivial `SwitchInt` terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the `SimplifyCfg` optimization was removing `SwitchInt` terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that `SwitchInt` terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory.
This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB.
Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like:
```rust
fn foo() {
let x;
let (0 | _) = x;
}
```
This match expression should perform a read because `_` does not shadow the `0` literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: rust-lang#139042 (comment)
As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like `0 | _`), then we should be enabling this behavior *after* fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.:
```rust
fn foo() {
let x;
let (0.. | _) = x;
}
```
add next_index to Enumerate Proposal: rust-lang/libs-team#435 Tracking Issue: rust-lang#130711 This basically just reopens rust-lang#130682 but squashed and with the new function and the feature gate renamed to `next_index.` There are two questions I have already: - Shouldn't we add test coverage for that? I'm happy to provide some, but I might need a pointer to where these test would be. - Maybe I could actually also add a doctest? - For now, I just renamed the feature name in the unstable attribute to `next_index`, as well, so it matches the new name of the function. Is that okay? And can I just do that and use any string, or is there a sealed list of features defined somewhere where I also need to change the name?
…ns, r=Mark-Simulacrum Setup editor file associations for non-rs extensions .gitattributes lists `*.fixed`, `*.pp`, and `*.mir` as file extensions which should be treated as Rust source code. Do the same for VS Code and Zed. This only does syntax highlighting, which is appropriate, as MIR isn't really Rust code. At the same time, consistently order `rust-analyzer.linkedProjects` between editors. For some reason, Eglot didn't include `library/Cargo.toml`. I have tested this with VS Code and Zed. I have not implemented it for Emacs/Eglot or Helix.
…onur-ozkan skip llvm-config in autodiff check builds, when its unavailable As you suggested, this indeed fixes `./x.py check` builds when autodiff is enabled. r? ```@onur-ozkan``` closes rust-lang#139936 Tracking: - rust-lang#124509
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#134446 (Stabilize the `cell_update` feature) - rust-lang#139307 (std: Add performance warnings to HashMap::get_disjoint_mut) - rust-lang#139450 (Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo`) - rust-lang#139809 (Don't warn about `v128` in wasm ABI transition) - rust-lang#139852 (StableMIR: Implement `CompilerInterface`) - rust-lang#139945 (Extend HIR to track the source and syntax of a lifetime) - rust-lang#140028 (`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns) - rust-lang#140181 (Remove `synstructure::Structure::underscore_const` calls.) - rust-lang#140232 (Remove unnecessary clones) r? `@ghost` `@rustbot` modify labels: rollup
…oli-obk mitigate MSVC alignment issue on x86-32 This implements mitigation for rust-lang#112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems. Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can. Also add an errata note to the platform support page warning users about this known problem. try-job: `i686-msvc*`
Mention average in midpoint documentations Added a mention to "average" in midpoint documentations and as well as some `#[doc(alias = "average")]`[^1]. This is done to improve the discoverability of the function. [^1]: https://docs.rs/num-integer/latest/num_integer/trait.Average.html#tymethod.average_floor
…atrieb Update doc of cygwin target Some trivial updates.
…rrors Rename `compute_x` methods r? ```@lcnr``` I find the `compute_x` naming scheme to be overly confusing. It means `compute_wf_obligations_for_x_and_add_them_to_self` but shortens out all of the important parts of the actual operation being performed. `compute_x` sounds like its somehow performing `x`, maybe even returning it from the function, which is not true. I've had some newer contributors be confused by this naming scheme so I think it's good to change it to something more self-evident Some misc drive by niceties while I was here too.
…les, r=bjorn3 minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes` To preserve CFI directives in assembly tests, as `//@ add-core-stubs` already imply `-C panic=abort`. This is a blocker for rust-lang#140037 (comment). cc ```@RalfJung``` r? ```@bjorn3```
…youxu triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes Just routine triagebot labelling/mentioning changes. r? ```@ghost```
Remove comment about handling non-global where bounds with corresponding projection This comment is no longer relevant since we only assemble rigid projections if no param-env candidates hold. Also remove a stray comment from the old solver. r? lcnr
…covery, r=jieyouxu Revert overzealous parse recovery for single colons in paths Basically manually reverts rust-lang#136808, cc ``@chenyukang`` ``@estebank.`` Reopens rust-lang#129273. Fixes [after beta backport] rust-lang#140227.
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#139261 (mitigate MSVC alignment issue on x86-32) - rust-lang#140075 (Mention average in midpoint documentations) - rust-lang#140184 (Update doc of cygwin target) - rust-lang#140186 (Rename `compute_x` methods) - rust-lang#140194 (minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`) - rust-lang#140195 (triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes) - rust-lang#140214 (Remove comment about handling non-global where bounds with corresponding projection) - rust-lang#140228 (Revert overzealous parse recovery for single colons in paths) r? `@ghost` `@rustbot` modify labels: rollup
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc
implements rust-lang#136067
Rust has helper methods for many kinds of safe transmutes, for example integer<->bytes. This is a lint against using transmute for these cases.
```rs
fn bytes_at_home(x: [u8; 4]) -> u32 {
transmute(x)
}
// other examples
transmute::<[u8; 2], u16>();
transmute::<[u8; 8], f64>();
transmute::<u32, [u8; 4]>();
transmute::<char, u32>();
transmute::<u32, char>();
```
It would be handy to suggest `u32::from_ne_bytes(x)`.
This is implemented for `[u8; _]` -> `{float int}`
This also implements the cases:
`fXX` <-> `uXX` = `{from_bits, to_bits}`
`uXX` -> `iXX` via `cast_unsigned` and `cast_signed`
{`char` -> `u32`, `bool` -> `n8`} via `from`
`u32` -> `char` via `from_u32_unchecked` (note: notes `from_u32().unwrap()`) (contested)
`u8` -> `bool` via `==` (debatable)
---
try-job: aarch64-gnu
try-job: test-various
…li-obk Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions` This makes them warn whenever a plain `u128`/`i128` would. If the lang team decides to merge rust-lang#137306 then this can be reverted. Tracking issue: rust-lang#56071
Autodiff flags Interestingly, it seems that some other projects have conflicts with exactly the same LLVM optimization passes as autodiff. At least `LLVMRustOptimize` has exactly the flags that we need to disable problematic opt passes. This PR enables us to compile code where users differentiate two identical functions in the same module. This has been especially common in test cases, but it's not impossible to encounter in the wild. It also enables two new flags for testing/debugging. I consider writing an MCP to upgrade PrintPasses to be a standalone -Z flag, since it is *not* the same as `-Z print-llvm-passes`, which IMHO gives less useful output. A discussion can be found here: [#t-compiler/llvm > Print llvm passes. @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/Print.20llvm.20passes.2E/near/511533038) Finally, it improves `PrintModBefore` and `PrintModAfter`. They used to work reliable, but now we just schedule enzyme as part of an existing ModulePassManager (MPM). Since Enzyme is last in the MPM scheduling, PrintModBefore became very inaccurate. It used to print the input module, which we gave to the Enzyme and was great to create llvm-ir reproducer. However, lately the MPM would run the whole `default<O3>` pipeline, which heavily modifies the llvm module, before we pass it to Enzyme. That made it impossible to use the flag to create llvm-ir reproducers for Enzyme bugs. We now schedule a PrintModule pass just before Enzyme, solving this problem. Based on the PrintPass output, it also _seems_ like changing `registerEnzymeAndPassPipeline(PB, true);` to `registerEnzymeAndPassPipeline(PB, false);` has no effect. In theory, the bool should tell Enzyme to schedule some helpful passes in the PassBuilder. However, since it doesn't do anything and I'm not 100% sure anymore on whether we really need it, I'll just disable it for now and postpone investigations. r? ``@oli-obk`` closes rust-lang#139471 Tracking: - rust-lang#124509
… r=Amanieu
rustc_target: Adjust RISC-V feature implication
This commit adjusts feature implication of the RISC-V ISA for better feature detection from the user perspective.
The main rule is:
* If the feature `A` is a functional superset of the feature `B` (`A ⊃ B`),
`A` is to imply `B`, even if this implication is not on the manual.
Such implications (not directly written in the ISA manual) are commented as `A ⊃ B`
which means "`A` is a (functional) superset of `B`".
1. `Zbc` → `Zbkc` (add as a superset)
The `Zbkc` extension is a subset of the `Zbc` extension (`Zbc` minus `clmulr` instruction).
2. `Zkr` → (nothing) (remove dependency to `Zicsr`)
Implication to the `Zicsr` extension is removed because (although nearly harmless), the `Zkr` extension (or the `seed` CSR section) defines its own subset of the `Zicsr` extension (guaranteed to work against the `seed` CSR which needs read/write access).
3. `Zvbb` → `Zvkb` (comment as a superset)
This implication was already there but not denoted as a functional superset. This commit adds the comment.
4. `Zvfh` → `Zvfhmin` (comment as a superset)
This is similar to the case above (`Zvbb` → `Zvkb`).
5. `Zvfh` → `Zve32f` (add implication per the ISA specification)
This dependency is on the ISA manual but was missing (due to the fact that `Zvfh` indirectly implies `Zve32f` on the current implementation through `Zvfh` → `Zvfhmin` which is a functional relation). This commit ensures that this is *also* ISA-compliant in the source code level (there's no functional changes though).
6. `Zvknhb` → `Zvknha` (add as a superset)
The `Zvknhb` extension (SHA-256 / SHA-512) is a functional superset of the `Zvknha` extension (SHA-256 only).
Move zkVM constants into `sys::env_consts` I missed this in rust-lang#139868. Its `mod` declaration was removed, but the contents were not moved. r? joboet
fix MAX_EXP and MIN_EXP docs As pointed out in rust-lang#88734, the docs for these constants are wrong. r? ``@tgross35``
…r=RalfJung Make algebraic functions into `const fn` items. Tracking issue: rust-lang#136469 This PR makes the algebraic intrinsics and the unstable, algebraic functions of `f16`, `f32`, `f64`, and `f128` into `const fn` items: ```rust impl f16 { pub const fn algebraic_add(self, rhs: f16) -> f16; pub const fn algebraic_sub(self, rhs: f16) -> f16; pub const fn algebraic_mul(self, rhs: f16) -> f16; pub const fn algebraic_div(self, rhs: f16) -> f16; pub const fn algebraic_rem(self, rhs: f16) -> f16; } impl f32 { pub const fn algebraic_add(self, rhs: f32) -> f32; pub const fn algebraic_sub(self, rhs: f32) -> f32; pub const fn algebraic_mul(self, rhs: f32) -> f32; pub const fn algebraic_div(self, rhs: f32) -> f32; pub const fn algebraic_rem(self, rhs: f32) -> f32; } impl f64 { pub const fn algebraic_add(self, rhs: f64) -> f64; pub const fn algebraic_sub(self, rhs: f64) -> f64; pub const fn algebraic_mul(self, rhs: f64) -> f64; pub const fn algebraic_div(self, rhs: f64) -> f64; pub const fn algebraic_rem(self, rhs: f64) -> f64; } impl f128 { pub const fn algebraic_add(self, rhs: f128) -> f128; pub const fn algebraic_sub(self, rhs: f128) -> f128; pub const fn algebraic_mul(self, rhs: f128) -> f128; pub const fn algebraic_div(self, rhs: f128) -> f128; pub const fn algebraic_rem(self, rhs: f128) -> f128; } // core::intrinsics pub const fn fadd_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn fsub_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn fmul_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn fdiv_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn frem_algebraic<T: Copy>(a: T, b: T) -> T; ``` This PR does not preserve the initial behaviour of these functions yielding non-deterministic output under Miri; it is most likely desired to reimplement this behaviour at some point.
…git-config, r=jieyouxu Remove git repository from git config It is no longer needed after rust-lang#138591. We could even remove the `nightly_branch` field, but it still has one usage. r? ``@jieyouxu``
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136083 (Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc) - rust-lang#138282 (Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions`) - rust-lang#139700 (Autodiff flags) - rust-lang#140139 (rustc_target: Adjust RISC-V feature implication) - rust-lang#140141 (Move zkVM constants into `sys::env_consts`) - rust-lang#140150 (fix MAX_EXP and MIN_EXP docs) - rust-lang#140172 (Make algebraic functions into `const fn` items.) - rust-lang#140191 (Remove git repository from git config) r? `@ghost` `@rustbot` modify labels: rollup
set subsections_via_symbols for ld64 helper sections closes rust-lang#139744 cc `@madsmtm`
Shourya742
force-pushed
the
2025-03-29-add-autodiff-inline
branch
3 times, most recently
from
48d05aa to
bbb9f6c
Compare
Shourya742
force-pushed
the
2025-03-29-add-autodiff-inline
branch
from
30f55e0 to
7018392
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.