-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 10 pull requests #137900
Rollup of 10 pull requests #137900
Conversation
with where to *actually* look for more details
There is a subtlety which "other conditions must be upheld by the caller" does not capture: `GlobalAlloc`/`alloc::dealloc()` require that the provided layout will be *equal*, not just that it "fits", the layout used to allocate. This is always true here due to how `allocate()`, `grow()`, and `shrink()` are implemented (they never return a larger allocation than requested), but that is a non-local property of the implementation, so it should be documented explicitly.
Wasmtime's `--wasm-features` and `--wasi-modules` flags have been renamed since these docs were initially written. Additionally, from my testing I don't believe `--wasm threads` is needed if `--wasi threads` is passed already.
One-sided ranges are never empty
LLVM has crashes at some `half` operations when built with assertions enabled if fp-armv8 is not available [1]. Things seem to usually work, but we are reaching LLVM undefined behavior so this needs to be disabled. [1]: llvm/llvm-project#129394
Use `DefId.name` and `DefId.trimmed_name` instead
Reference `DefId` in `CrateDef` docs to avoid duplicating long description of `trimmed_name`
…, r=Mark-Simulacrum Minor internal comments fix for `BufRead::read_line` Just a little fix that came up while I was reading through this source code, and had to search for a few minutes to find out what was actually *meant* here.
More precisely document `Global::deallocate()`'s safety. There is a subtlety which "other conditions must be upheld by the caller" does not capture: `GlobalAlloc`/`alloc::dealloc()` require that the provided layout will be *equal*, not just that it "fits", the layout used to allocate. This is always true here due to how `allocate()`, `grow()`, and `shrink()` are implemented (they never return a larger allocation than requested), but that is a non-local property of the implementation, so it should be documented explicitly. r? libs `@rustbot` label A-allocators
…=Noratrieb doc: update Wasmtime flags Wasmtime's `--wasm-features` and `--wasi-modules` flags have been renamed since these docs were initially written. Additionally, from my testing I don't believe `--wasm threads` is needed if `--wasi threads` is passed already.
…ned, r=workingjubilee improve `simd_select` error message when used with invalid mask type followup to rust-lang#137828 This PR improves the error message for an invalid `simd_select` mask type, and adds testing for `simd_scatter` and `simd_gather` being used with invalid mask types. the `simd_masked_load` and `simd_masked_store` intrinsics already generated a better error message: https://github.com/rust-lang/rust/blob/0c72c0d11adeba449886089c6bd5d48363f7a2cd/tests/ui/simd/masked-load-store-build-fail.rs#L24-L37 r? `@workingjubilee`
…gjubilee rustc_target: Add msync target feature and enable it on powerpcspe targets Some older PowerPC processors do not have the `sync` (`sync 0`) and `lwsync` (`sync 1`) instructions, but instead have the `msync` instruction. (IIRC `msync` and `sync` will be assembled into the same bit-pattern, but `lwsync` will be SIGILL. See also https://gcc.gnu.org/legacy-ml/gcc-patches/2006-11/msg01238.html.) LLVM recognizes this as the [`msync` feature](https://github.com/llvm/llvm-project/blob/cc5d8a4b2fc765c3c432f1ad0b185dae518d41bd/llvm/lib/Target/PowerPC/PPC.td#L140) and enables for some cpus such as [e500](https://github.com/llvm/llvm-project/blob/cc5d8a4b2fc765c3c432f1ad0b185dae518d41bd/llvm/lib/Target/PowerPC/PPC.td#L644). powerpcspe is a target for CPUs such as e500 ([Debian Wiki](https://wiki.debian.org/PowerPCSPEPort)). However, the `msync` feature is currently not enabled except for vxworks, and at least since 2022-04, powerpc-unknown-linux-gnuspe was known to not work on real hardware without `-C target-cpu` (e.g., rust-lang#96394, rust-lang#117361). https://github.com/rust-lang/rust/blob/8c392966a013fd8a09e6b78b3c8d6e442bc278e1/compiler/rustc_target/src/spec/targets/powerpc_wrs_vxworks_spe.rs#L28 Fixes rust-lang#117361 cc `@BKPepe` ([powerpc-unknown-linux-muslspe target maintainer](https://doc.rust-lang.org/nightly/rustc/platform-support/powerpc-unknown-linux-muslspe.html#target-maintainers)) cc `@glaubitz` (who added powerpc-unknown-linux-gnuspe in rust-lang#48484) cc `@th0ma7` (who opened rust-lang#117361) r? workingjubilee `@rustbot` label +O-PowerPC +A-target-feature
…ct, r=scottmcm fix `RangeBounds::is_empty` documentation One-sided ranges are never empty follow-up for rust-lang#137304 (review)
… r=workingjubilee Disable `f16` on Aarch64 without `neon` LLVM has crashes at some `half` operations when built with assertions enabled if fp-armv8 is not available [1]. Things seem to usually work, but we are reaching LLVM undefined behavior so this needs to be disabled. [1]: llvm/llvm-project#129394
…ouxu Adjust triagebot.toml entries for `rustc_mir_build/src/builder/` I only just noticed that these paths were silently broken by the renaming of `build` to `builder` in rust-lang#134365. This is *possibly* OK to just self-approve, but I would prefer to get a second set of eyes on it just in case.
…rieb edit mailmap
`name()` and `trimmed_name()` for `stable_mir::crate_def::DefId` Resolves rust-lang/project-stable-mir#91 * Added `stable_mir::crate_def::DefId::name()` and `stable_mir::crate_def::DefId::trimmed_name()` methods * Changed `CrateDef` and `DefId` `Debug` implementations to use new methods instead of copy-paste call to `Context::def_name` * Updated docs to avoid duplicating description of what `name` and `trimmed_name` do
@bors r+ rollup=never p=4 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: daf59857d6 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (81d8edc): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary -9.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 773.006s -> 772.867s (-0.02%) |
Successful merges:
BufRead::read_line
#137375 (Minor internal comments fix forBufRead::read_line
)Global::deallocate()
's safety. #137641 (More precisely documentGlobal::deallocate()
's safety.)simd_select
error message when used with invalid mask type #137851 (improvesimd_select
error message when used with invalid mask type)RangeBounds::is_empty
documentation #137871 (fixRangeBounds::is_empty
documentation)f16
on Aarch64 withoutneon
#137873 (Disablef16
on Aarch64 withoutneon
)rustc_mir_build/src/builder/
#137876 (Adjust triagebot.toml entries forrustc_mir_build/src/builder/
)name()
andtrimmed_name()
forstable_mir::crate_def::DefId
#137886 (name()
andtrimmed_name()
forstable_mir::crate_def::DefId
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup