Batchmode #192
Open
Batchmode #192
Conversation
This file contains 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
Signed-off-by: chloefeal <[email protected]>
Including implementing it for `u128`, so it can be defined in `uint_impl!`. This way it works for all backends, including CTFE.
Strip debuginfo from rustc-main and rustdoc r? `@Kobzol` Split from rust-lang#134690
Add a compiler intrinsic to back `bigint_helper_methods` cc rust-lang#85532 This adds a new `carrying_mul_add` intrinsic, to implement `wide_mul` and `carrying_mul`. It has fallback MIR for all types -- including `u128`, which isn't currently supported on nightly -- so that it'll continue to work on all backends, including CTFE. Then it's overridden in `cg_llvm` to use wider intermediate types, including `i256` for `u128::carrying_mul`.
Make `ty::Error` implement all auto traits I have no idea what's up with the crashes test I fixed--I really don't want to look into it since it has to do something with borrowck and multiple layers of opaques. I think the underlying idea of allowing error types to implement all auto traits is justified though. Fixes rust-lang#134796 Fixes rust-lang#131050 r? lcnr
…r, r=jieyouxu compiletest: Remove empty 'expected' files when blessing Fixes rust-lang#134793 Fixes rust-lang#134196 This also refactors `compare_output` to return an enum; returning a usize was done for convenience but is misleading
Add `--no-capture`/`--nocapture` as bootstrap arguments I often try `x test ... --nocapture` => 'unknown argument' => `x test ... -- --nocapture`. As we forward several other compiletest flags, let's recognise this one in bootstrap as well.
Add spastorino to users_on_vacation
Add clubby789 back to bootstrap review rotation
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#133663 (Add a compiler intrinsic to back `bigint_helper_methods`) - rust-lang#134798 (Make `ty::Error` implement all auto traits) - rust-lang#134808 (compiletest: Remove empty 'expected' files when blessing) - rust-lang#134809 (Add `--no-capture`/`--nocapture` as bootstrap arguments) - rust-lang#134826 (Add spastorino to users_on_vacation) - rust-lang#134828 (Add clubby789 back to bootstrap review rotation) r? `@ghost` `@rustbot` modify labels: rollup
Nothing significant here, just syncing the following small changes: - rust-lang/compiler-builtins#727 - rust-lang/compiler-builtins#730 - rust-lang/compiler-builtins#736 - rust-lang/compiler-builtins#737
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this
Co-authored-by: David Tolnay <[email protected]>
Fix typos This PR focuses on correcting typos and improving clarity in documentation files. Thank you.
Some random region tweaks Remove a redundant function and add an assertion that I think is useful
…r-errors
Skip parenthesis if `.` makes statement boundary unambiguous
There is a rule in the parser that statements and match-arms never end in front of a `.` or `?` token (except when the `.` is really `..` or `..=` or `...`). So some of the leading subexpressions that need parentheses inserted when followed by some other operator like `-` or `+`, do not need parentheses when followed by `.` or `?`.
Example:
```rust
fn main() {
loop {}.to_string() + "";
match () {
_ => loop {}.to_string() + "",
};
}
```
`-Zunpretty=expanded` before:
```console
#![feature(prelude_import)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
fn main() {
(loop {}).to_string() + "";
match () { _ => (loop {}).to_string() + "", };
}
```
After:
```console
#![feature(prelude_import)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
fn main() {
loop {}.to_string() + "";
match () { _ => loop {}.to_string() + "", };
}
```
…rors
Skip parenthesis around tuple struct field calls
The pretty-printer previously did not distinguish between named vs unnamed fields when printing a function call containing a struct field. It would print the call as `(self.fun)()` for a named field which is correct, and `(self.0)()` for an unnamed field which is redundant.
This PR changes function calls of tuple struct fields to print without parens.
**Before:**
```rust
struct Tuple(fn());
fn main() {
let tuple = Tuple(|| {});
(tuple.0)();
}
```
**After:**
```rust
struct Tuple(fn());
fn main() {
let tuple = Tuple(|| {});
tuple.0();
}
```
Rollup of 4 pull requests Successful merges: - rust-lang#134823 (Fix typos) - rust-lang#134827 (Some random region tweaks) - rust-lang#134833 (Skip parenthesis if `.` makes statement boundary unambiguous) - rust-lang#134834 (Skip parenthesis around tuple struct field calls) r? `@ghost` `@rustbot` modify labels: rollup
…iler-errors
Provide structured suggestion for `impl Default` of type where all fields have defaults
```
error: `Default` impl doesn't use the declared default field values
--> $DIR/manual-default-impl-could-be-derived.rs:28:1
|
LL | / impl Default for B {
LL | | fn default() -> Self {
LL | | B {
LL | | x: s(),
| | --- this field has a default value
LL | | y: 0,
| | - this field has a default value
... |
LL | | }
| |_^
|
help: to avoid divergence in behavior between `Struct { .. }` and `<Struct as Default>::default()`, derive the `Default`
|
LL ~ #[derive(Default)] struct B {
|
```
Note that above the structured suggestion also includes completely removing the manual `impl`, but the rendering doesn't.
Rollup of 6 pull requests Successful merges: - rust-lang#131439 (Remove allowing static_mut_refs lint) - rust-lang#133292 (E0277: suggest dereferencing function arguments in more cases) - rust-lang#134877 (add suggestion for wrongly ordered format parameters) - rust-lang#134945 (Some small nits to the borrowck suggestions for mutating a map through index) - rust-lang#134950 (bootstrap: Overhaul and simplify the `tool_check_step!` macro) - rust-lang#134979 (Provide structured suggestion for `impl Default` of type where all fields have defaults) r? `@ghost` `@rustbot` modify labels: rollup
…merjake char to_digit: avoid unnecessary casts to u64 Hello, in the `char::to_digit` method there are a few `as u64` casts that are not strictly necessary. I assume that the reason behind these casts is to avoid possible overflows in the `+ 10` add. This PR removes the aforementioned casts, avoiding the overflow issue by slightly modifying the ASCII letter to int mapping. Thanks, Happy new year.
Since Emscripten uses musl libc internally. Non-functional change: all LFS64 symbols were aliased to their non-LFS64 counterparts in rust-lang/libc@7c952dc.
Align it with musl, which also prefers using lstat() here.
It was not working for a long time.
Run Python formatting check in tidy on CI I don't think that there's a reason why we should ignore Python formatting on CI, when we already check Python lints and C++ formatting. r? `@onur-ozkan`
…Noratrieb Avoid use of LFS64 symbols on Emscripten Since Emscripten uses musl libc internally. Non-functional change: all LFS64 symbols were aliased to their non-LFS64 counterparts in rust-lang/libc@7c952dc.
… r=jieyouxu handle submodules automatically on `doc` steps Helps to make `doc` macros less complicated.
Fix typos This PR fixes typos errors in comments and docs. Thank you very much.
… r=lqd `ObligationCause` construction tweaks in typeck Mostly just consolidating the way we construct obligations in `FnCtxt`.
…cation-in-Ord-trait-docs, r=Noratrieb Remove qualification of `std::cmp::Ordering` in `Ord` doc
…pe, r=lqd Fix ICE when opaque captures a duplicated/invalid lifetime See description on test. Fixes rust-lang#132766 Fixes rust-lang#133693 Fixes rust-lang#134780
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#134967 (handle submodules automatically on `doc` steps) - rust-lang#134973 (Fix typos) - rust-lang#134984 (`ObligationCause` construction tweaks in typeck) - rust-lang#134985 (Remove qualification of `std::cmp::Ordering` in `Ord` doc) - rust-lang#135000 (Fix ICE when opaque captures a duplicated/invalid lifetime) r? `@ghost` `@rustbot` modify labels: rollup
Autodiff Upstreaming - rustc_codegen_llvm changes Now that the autodiff/Enzyme backend is merged, this is an upstream PR for the `rustc_codegen_llvm` changes. It also includes small changes to three files under `compiler/rustc_ast`, which overlap with my frontend PR (rust-lang#129458). Here I only include minimal definitions of structs and enums to be able to build this backend code. The same goes for minimal changes to `compiler/rustc_codegen_ssa`, the majority of changes there will be in another PR, once either this or the frontend gets merged. We currently have 68 files left to merge, 19 in the frontend PR, 21 (+3 from the frontend) in this PR, and then ~30 in the middle-end. This PR is large because it includes two of my three large files (~800 loc each). I could also first only upstream enzyme_ffi.rs, but I think people might want to see some use of these bindings in the same PR? To already highlight the things which reviewers might want to discuss: 1) `enzyme_ffi.rs`: I do have a fallback module to make sure that we don't link rustc against Enzyme when we build rustc without autodiff support. 2) `add_panic_msg_to_global` was a pain to write and I currently can't even use it. Enzyme writes gradients into shadow memory. Pass in one float scalar? We'll allocate and return an extra float telling you how this float affected the output. Pass in a slice of floats? We'll let you allocate the vector and pass in a mutable reference to a float slice, we'll then write the gradient into that slice. It should be at least as large as your original slice, so we check that and panic if not. Currently we panic silently, but I already generate a nicer panic message with this function. I just don't know how to print it to the user. yet. I discussed this with a few rustc devs and the best we could come up with (for now), was to look for mangled panic calls in the IR and pick one, which works surprisingly reliably. If someone knows a good way to clean this up and print the panic message I'm all in, otherwise I can remove the code that writes the nicer panic message and keep the silent panic, since it's enough for soundness. Especially since this PR is already a bit larger. 3) `SanitizeHWAddress`: When differentiating C++, Enzyme can use TBAA to "understand" enums/unions, but for Rust we don't have this information. LLVM might to speculative loads which (without TBAA) confuse Enzyme, so we disable those with this attribute. This attribute is only set during the first opt run before Enzyme differentiates code. We then remove it again once we are done with autodiff and run the opt pipeline a second time. Since enums are everywhere in Rust, support for them is crucial, but if this looks too cursed I can remove these ~100 lines and keep them in my fork for now, we can then discuss them separately to make this PR simpler? 4) Duplicated llvm-opt runs: Differentiating already optimized code (and being able to do additional optimizations on the fly, e.g. for GPU code) is _the_ reason why Enzyme is so fast, so the compile time is acceptable for autodiff users: https://enzyme.mit.edu/talks/Publications/ (There are also algorithmic issues in Enzyme core which are more serious than running opt twice). 5) I assume that if we merge these minimal cg_ssa changes here already, I also need to fix the other backends (GCC and cliff) to have dummy implementations, correct? 6) *I'm happy to split this PR up further if reviewers have recommendations on how to.* For the full implementation, see: rust-lang#129175 Tracking: - rust-lang#124509
Turn rustc-dev-guide into a Josh subtree Discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/196385-t-compiler.2Fwg-rustc-dev-guide/topic/a.20move.20to.20main.20repo.20.28rust-lang.2Frust.29). Accompanying rustc-dev-guide PR: rust-lang/rustc-dev-guide#2183 I didn't create a bootstrap step for rustc-dev-guide yet, because the rustc-dev-guide version that we currently use in this repo doesn't have linkcheck enabled and that fails tests. The subtree starts with commit [ad93c5f1c49f2aeb45f7a4954017b1e607df9f5e](rust-lang/rustc-dev-guide@ad93c5f). What I did: ``` export DIR=src/doc/rustc-dev-guide # Remove submodule git submodule status ${DIR} git submodule deinit ${DIR} git rm -r --cached ${DIR} rm -rf ${DIR} # Remove rustc-dev-guide from .gitmodules git commit -m"Removed `${DIR}` submodule" # Import history with josh git fetch https://github.com/rust-lang/rustc-dev-guide ad93c5f1c49f2aeb45f7a4954017b1e607df9f5e josh-filter ':prefix=src/doc/rustc-dev-guide' FETCH_HEAD git merge --allow-unrelated FILTERED_HEAD # A few follow-up cleanup commits ``` r? ehuss
7 tasks
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.
Let's expose Enzyme's batchmode (independent of AD).