Rollup of 24 pull requests#157794
Conversation
Replace uses of `u8` with a generic type. This will allow reusing `BorrowedBuf` elsewhere in the standard library, for purposes other than byte buffers. This currently requires `T: Copy`, to prevent `T: Drop`, which would require additional careful handling. We can consider relaxing that restriction in the future if we make `T: Drop` work (without pessimizing `Copy` types like `u8`). `ensure_init` currently continues to require `u8`. We could potentially generalize it to `T: Default`, but we'd need to ensure it produced the same or better assembly for `u8`.
This default simplified the commit making these types generic, but we don't actually want the default. Rewrite every user to specify `u8` explicitly.
Now that the `impl` block has a bound, the one on `append` became redundant.
An unconstrained `TransmuteFrom` obligation used to ICE with `layout_of: unexpected type` under the next-gen trait solver; it now reports `type annotations needed` (E0283). Add a regression test for that case, which the fix's own test suite did not cover.
When pointing at each step of cycle errors, do not include the code snippet when the note points at the same place as the previous one (by setting the note's span to DUMMY_SP).
Co-authored-by: Ryan Mehri <52933714+rmehri01@users.noreply.github.com>
This is effectively dead code now that we validate the target spec, so let's mark it as unreachable to avoid misleading people looking at this code.
Add support for inline assembly for the amdgpu backend (the amdgcn-amd-amdhsa target). Add register classes for `vgpr` (vector general purpose register) and `sgpr` (scalar general purpose register). The LLVM backend supports two more classes, `reg`, which is either VGPR or SGPR, up to the compiler to decide. As instructions often rely on a register being either a VGPR or SGPR for the assembly to be valid, reg doesn’t seem that useful (I struggled to write correct tests for it), so I didn’t end up adding it. The fourth register class is AGPRs, which only exist on some hardware versions (not the consumer ones) and they have restricted ways to write and read from them, which makes it hard to write a Rust variable into them. They could be used inside assembly blocks, but I didn’t add them as Rust register class. There are a few change affecting general inline assembly code, that is `InlineAsmReg::name()` now returns a `Cow` instead of a `&'static str`. Because amdgpu has many registers, 256 VGPRs plus combinations of 2 or 4 VGPRs, and I didn’t want to list hundreds of static strings, the amdgpu reg stores the register number(s) and a non-static String is generated at runtime for the register name. Similar for register classes and supported_types. Vectors of 64-bit types are supported by the LLVM backend, but omitted here to make the code simpler. There is currently no systematic support in LLVM of which vectors of 64-bit types are supported. Also, they are likely seldomly unused, vectors of 16- and 32-bit types are important.
A macro can expand to several missing-type items (e.g. a `$()*` repetition of `const A = ...;`) that all collide on one stashed `ItemNoType` diagnostic. They can infer different types, so there is no single concrete type to suggest, and which item wins the steal is not even stable under the parallel front-end. Skip the inferred-type suggestion when the placeholder span comes from a macro expansion and keep the generic `<type>` suggestion from the parser instead, mirroring the existing handling in the fallback arm. This makes the diagnostic deterministic, so the `in-macro` test no longer needs `ignore-parallel-frontend`.
As discussed in the long-closed issue referenced by the FIXMEs, it would be unsound to add nocapture to all reference arguments. The canonical example is taking &T and returning *const T, i.e., `std::ptr::from_ref`. Some of the removed test cases suggest that named vs elided vs static lifetime on the reference would make a difference for capturing, which is incompatible with all modern takes on Rust opsem. Hypothetically, we could add some kind of escape analysis on MIR to determine which arguments can be marked as nocapture. But LLVM can do that too (often better), so why should we? Plus, if we started doing such analysis, the test that had the FIXMEs would not be a good place to exercise it, as all the function bodies are trivial.
This comment has been minimized.
This comment has been minimized.
Rollup of 24 pull requests try-job: x86_64-msvc-ext1
|
@bors rollup=never |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing b30f3df (parent) -> 09a3713 (this PR) Test differencesShow 1020 test diffsStage 1
Stage 2
(and 2 additional test diffs) Additionally, 918 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 09a371361240e42b0d69438fd1179efcf212e576 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
📌 Perf builds for each rolled up PR:
previous master: b30f3df3ba In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (09a3713): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.9%, secondary -0.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeResults (primary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 518.98s -> 517.481s (-0.29%) |
|
The gains clearly outweigh the 2 minor secondary regressions, both of which are @rustbot label +perf-regression-triaged |
Successful merges:
BorrowedBufandBorrowedCursorgeneric over the data #149749 (MakeBorrowedBufandBorrowedCursorgeneric over the data)-Zinternal-testing-features#156212 (Additionally gate negative bounds behind new-Zinternal-testing-features)maybe_unused_trait_imports#157713 (resolve: Remove exported imports frommaybe_unused_trait_imports)tests/ui/issues[7/N] #157737 (Reorganizetests/ui/issues[7/N])r? @ghost
Create a similar rollup