Automatic Rustup #3980
Merged
Automatic Rustup #3980
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
Make destructors on `extern "C"` frames to be executed This would make the example in #123231 print "Noisy Drop". I didn't mark this as fixing the issue because the behaviour is yet to be spec'ed. Tracking: - rust-lang/rust#74990
optimize str.replace Adds a fast path for str.replace for the ascii to ascii case. This allows for autovectorizing the code. Also should this instead be done with specialization? This way we could remove one branch. I think it is the kind of branch that is easy to predict though. Benchmark for the fast path (replace all "a" with "b" in the rust wikipedia article, using criterion) : | N | Speedup | Time New (ns) | Time Old (ns) | |----------|---------|---------------|---------------| | 2 | 2.03 | 13.567 | 27.576 | | 8 | 1.73 | 17.478 | 30.259 | | 11 | 2.46 | 18.296 | 45.055 | | 16 | 2.71 | 17.181 | 46.526 | | 37 | 4.43 | 18.526 | 81.997 | | 64 | 8.54 | 18.670 | 159.470 | | 200 | 9.82 | 29.634 | 291.010 | | 2000 | 24.34 | 81.114 | 1974.300 | | 20000 | 30.61 | 598.520 | 18318.000 | | 1000000 | 29.31 | 33458.000 | 980540.000 |
Avoid superfluous UB checks in `IndexRange` `IndexRange::len` is justified as an overall invariant, and `take_prefix` and `take_suffix` are justified by local branch conditions. A few more UB-checked calls remain in cases that are only supported locally by `debug_assert!`, which won't do anything in distributed builds, so those UB checks may still be useful. We generally expect core's `#![rustc_preserve_ub_checks]` to optimize away in user's release builds, but the mere presence of that extra code can sometimes inhibit optimization, as seen in #131563.
Various fixes for Xous This patchset includes several fixes for Xous that have crept in over the last few months: * The `adjust_process()` syscall was incorrect * Warnings have started appearing in `alloc` -- adopt the same approach as wasm, until wasm figures out a workaround * Dead code warnings have appeared in the networking code. Add `allow(dead_code)` as these structs are used as IPC values * Add support for `args` and `env`, which have been useful for running tests * Update `unwinding` to `0.2.3` which fixes the recent regression due to changes in `asm!()` code
rustc_metadata: minor tidying Cleaned up some code while investigating #131720. See individual commits.
…er-errors Allow dropping dyn principal Revival of #126660, which was a revival of #114679. Fixes #126313. Allows dropping principal when coercing trait objects, e.g. `dyn Debug + Send` -> `dyn Send`. cc `@compiler-errors` `@Jules-Bertholet` r? `@lcnr`
Rollup of 5 pull requests Successful merges: - #131654 (Various fixes for Xous) - #131743 (rustc_metadata: minor tidying) - #131823 (Bump libc to 0.2.161) - #131850 (Missing parenthesis) - #131857 (Allow dropping dyn principal) r? `@ghost` `@rustbot` modify labels: rollup
…acrum CI: use free runners for 4-core Linux jobs It looks like the [free runners](https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories) already have the same spec as the `4c` custom "large" runner (4 cores, 16 GiB of memory, Ubuntu 20.04). try-job: arm-android try-job: armhf-gnu try-job: dist-aarch64-linux try-job: dist-android try-job: dist-arm-linux try-job: dist-armhf-linux try-job: dist-armv7-linux try-job: dist-i586-gnu-i586-i686-musl try-job: dist-i686-linux try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl try-job: dist-ohos try-job: dist-powerpc-linux try-job: dist-powerpc64-linux try-job: dist-powerpc64le-linux try-job: dist-riscv64-linux try-job: dist-s390x-linux try-job: dist-various-1 try-job: dist-various-2 try-job: dist-x86_64-freebsd try-job: dist-x86_64-illumos try-job: dist-x86_64-netbsd try-job: mingw-check try-job: test-various try-job: x86_64-gnu try-job: x86_64-gnu-stable try-job: x86_64-gnu-aux try-job: x86_64-gnu-debug try-job: x86_64-gnu-nopt
Abstract the state type for futexes
In the same way that we expose `SmallAtomic` and `SmallPrimitive` to allow Windows to use a value other than an `AtomicU32` for its futex state, switch the primary futex state type from `AtomicU32` to `futex::Futex`. The `futex::Futex` type should be usable as an atomic value with underlying primitive type equal to `futex::Primitive`. (`SmallAtomic` is also renamed to `SmallFutex`).
This allows supporting the futex API on systems where the underlying kernel futex implementation requires more user state than simply an `AtomicU32`.
All in-tree futex implementations simply define {`Futex`,`Primitive`} directly as {`AtomicU32`,`u32`}.
Make `profiler_builtins` an optional dependency of sysroot, not std This avoids unnecessary rebuilds of std (and the compiler) when `build.profiler` is toggled off or on. Fixes #131812. --- Background: The `profiler_builtins` crate has been an optional dependency of std (behind a cargo feature) ever since it was added back in #42433. But as far as I can tell that has only ever been a convenient way to force the crate to be built, not a genuine dependency. The side-effect of this false dependency is that toggling `build.profiler` causes a rebuild of std and the compiler, which shouldn't be necessary. This PR therefore makes `profiler_builtins` an optional dependency of the dummy sysroot crate (#108865), rather than a dependency of std. What makes this change so small is that all of the necessary infrastructure already exists. Previously, bootstrap would enable the `profiler` feature on the sysroot crate, which would forward that feature to std. Now, enabling that feature directly enables sysroot's `profiler_builtins` dependency instead. --- I believe this is more of a bootstrap change than a libs change, so tentatively: r? bootstrap
Return values larger than 2 registers using a return area pointer
LLVM and Cranelift disagree about how to return values that don't fit in the registers designated for return values. LLVM will force the entire return value to be passed by return area pointer, while Cranelift will look at each IR level return value independently and decide to pass it in a register or not, which would result in the return value being passed partially in registers and partially through a return area pointer.
While Cranelift may need to be fixed as the LLVM behavior is generally more correct with respect to the surface language, forcing this behavior in rustc itself makes it easier for other backends to conform to the Rust ABI and for the C ABI rustc already handles this behavior anyway.
In addition LLVM's decision to pass the return value in registers or using a return area pointer depends on how exactly the return type is lowered to an LLVM IR type. For example `Option<u128>` can be lowered as `{ i128, i128 }` in which case the x86_64 backend would use a return area pointer, or it could be passed as `{ i32, i128 }` in which case the x86_64 backend would pass it in registers by taking advantage of an LLVM ABI extension that allows using 3 registers for the x86_64 sysv call conv rather than the officially specified 2 registers.
This adjustment is only necessary for the Rust ABI as for other ABI's the calling convention implementations in rustc_target already ensure any return value which doesn't fit in the available amount of return registers is passed in the right way for the current target.
Helps with rust-lang/rustc_codegen_cranelift#1525
cc bytecodealliance/wasmtime#9250
std: uefi: Add basic Env variables - Implement environment variable functions - Using EFI Shell protocol.
small interpreter error cleanup - Add `InterpretResult::map_err_kind` for the common case of swapping out the error kind (while preserving the backtrace pointing to the original error source) - Rename `InterpError` -> `InterpErrorKind` to be consistent with the `kind` field name, and make it more clear that this is not the final error type
zero-sized accesses are fine on null pointers We entirely forgot to update all the function docs when changing the central docs. That's the problem with helpfully repeating shared definitions in tons of places...
Rollup of 8 pull requests Successful merges: - #127462 (std: uefi: Add basic Env variables) - #131537 (Fix range misleading field access) - #131838 (bootstrap: allow setting `--jobs` in config.toml) - #131890 (Update `use` keyword docs to describe precise capturing) - #131899 (Mark unexpected variant res suggestion as having placeholders) - #131908 (rustdoc: Switch from FxHash to sha256 for static file hashing.) - #131916 (small interpreter error cleanup) - #131919 (zero-sized accesses are fine on null pointers) r? `@ghost` `@rustbot` modify labels: rollup
Update `compiler-builtins` to 0.1.134 I'm modeling this PR after rust-lang/rust#131314. This pulls in rust-lang/compiler-builtins#713 which should mitigate the problem reported and discussed in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Hello.20World.20on.20sparc-unknown-none-elf.20crashes
refactor fudge_inference, handle effect vars this makes it easier to use fudging outside of `fudge_inference_if_ok`, which is likely necessary to handle inference variable leaks on rollback. We now also uses exhaustive matches where possible and improve the code to handle effect vars. r? `@compiler-errors` `@BoxyUwU`
Member
|
@bors r+ |
Contributor
Contributor
Contributor
|
☀️ Test successful - checks-actions |
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.