Repository navigation
Rollup of 7 pull requests - #163296
Rollup of 7 pull requests#163296
Conversation
The ELFv1 ABI only passes "one member aggregates" containing a floating
point value in floating point registers. A union with more than one
member is not a one member aggregate, but `homogeneous_aggregate` merges
the fields of a union, so e.g. `union { f32, f32 }` was passed in an FPR,
while GCC and clang both pass it in a GPR.
Reject as a one-member aggregate any layout that is or contains a union
with more than one non-1-ZST field.
The ELFv1 ABI defines aggregates as structures and arrays; unions are consistently listed separately. A union is therefore never a "one member aggregate", not even when it has a single field or when it is nested within a structure or array. Extend the previous commit to reject any layout that is or contains a union. This matches GCC in all cases. Clang still passes single-field unions (including nested ones) in FPRs, contrary to the specification; llvm/llvm-project#223481 fixes that.
…nts, before generating a jump to def link
In clang >= 23 the ABI for complex is incompatible with GCC. This has been fixed in llvm/llvm-project#212340 and will be part of clang 24
…agnostic, r=Amanieu Preserve explicit register names in inline asm diagnostics This PR adds diagnostic-only metadata directly to each register-bearing HIR operand, and replaces rust-lang#117912 AST lookup with the new HIR metadata. Fixes rust-lang#159409
…ression-suggestion, r=estebank
Fix applicability level for cfg suggestion
Mark the semicolon, block-wrapping, and if cfg! suggestions for attribute-bearing expressions as `MaybeIncorrect`.
For example:
```rust
fn native_file_attributes(metadata: &std::fs::Metadata) -> u32 {
#[cfg(unix)]
std::os::unix::fs::MetadataExt::mode(metadata)
#[cfg(windows)]
std::os::windows::fs::MetadataExt::file_attributes(metadata)
}
fn main() -> std::io::Result<()> {
let metadata = std::fs::metadata(std::env::current_exe()?)?;
println!(
"native file attributes: {:#x}",
native_file_attributes(&metadata)
);
Ok(())
}
```
Adding ; discards the return value on Unix.
Replacing #[cfg] with if cfg! also fails because disabled branches still undergo name resolution and type checking.
Wrapping the expression in a block works here, but still can fail when multiple cfg branches are enabled and the first block returns a non-unit value.
For example:
```rust
fn value() -> u8 {
#[cfg(all())]
1
#[cfg(all())]
2
}
```
r? @estebank
make `Complex` ABI GCC-compatible on sparc tracking issue: rust-lang#154023 In clang >= 23 the ABI for complex is incompatible with GCC. This has been fixed in llvm/llvm-project#212340 and will be part of clang 24. Verified with abi-cafe. r? beetrees
…, r=folkertdev,beetrees powerpc64: don't pass unions in FPRs on ELFv1 Fixes rust-lang#162011. The ELFv1 ABI only passes "one member aggregates" containing a floating point value in floating point registers. It defines aggregates as structures and arrays, and consistently lists unions separately, so a union is never a one member aggregate -- not even with a single field, and not when nested inside a structure or array. `homogeneous_aggregate` merges the fields of a union and so cannot tell a union from a structure, which meant e.g. `union { f32, f32 }` was passed in an FPR. Add `is_or_contains_union`, which walks the layout a second time (mirroring the array and 1-ZST handling in `homogeneous_aggregate`), and reject any layout that is or contains a union. This matches GCC in all cases. Clang still passes single-field unions in FPRs, contrary to the specification; llvm/llvm-project#223481 fixes that.
… r=Urgau [rustdoc] Correctly check that an item is not `doc(hidden)` with `--generate-link-to-definition` Needed for rust-lang#162808. The problem was that we only checked the item itself, not any of its parents. Fixed by adding a loop. r? @Urgau
…ze-align, r=thomcc Tweak Layout::from_size_align_unchecked safety comment This slightly tweaks wording of the Safety "contract" of Layout::from_size_align_unchecked. In my opinion, safety comments on function documentation should specify "here is how to safely use this function" rather than the more indirect form of "this function is unsafe because ...". In this case the current docs are clear to me on how to use the function properly, but Its very uncommon that I see the safety comment worded in this sort of roundabout way, and typically when I see it in other crates its a lower quality safety comment that says something like "this function is unsafe because it uses a raw pointer", so I may just associate it with being a more wrong way to write the docs anyways. Thought it worthwhile to open a PR for it to make it more direct and see what others think about "the ~right~ better way to word safety contracts"
…they moving div_ceil() to associated items macro Currently the div_ceil() method of unsigned NonZero is beeing generated inside the `nonzero_integer_signedness_dependent_impls` macro. This seems odd, as this macro seems to otherwise only be used for Trait impls, whereas associated methods like div_ceil() are all in the `nonzero_integer_signedness_dependent_methods` macro. If nothing else this causes an issue in the docs, where currently all unsigned NonZero types have two documented impl blocks, one containing only div_ceil(), and the other containing the remaining associated methods and constants. This PR assumes that this is accidental. If that is not the case then maybe the explanation should be documented somewhere instead.
|
@bors r+ p=5 force |
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 0d38a84 (parent) -> 7618355 (this PR) Test differencesShow 718 test diffsStage 1
Stage 2
Additionally, 706 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 7618355fd7d2681577129b93187d5cf3bff28dba --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 |
|
Finished benchmarking commit (7618355): comparison URL. Overall result: ✅ improvements - no action needed@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 (secondary -0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.8%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 491.128s -> 492.862s (0.35%) |
|
📌 Perf builds for each rolled up PR:
parent commit: 0d38a84262 In the case of a perf regression, run the following command with the SHAs of each PR you suspect might be the cause: |
Successful merges:
ComplexABI GCC-compatible on sparc #163025 (makeComplexABI GCC-compatible on sparc)doc(hidden)with--generate-link-to-definition#163268 ([rustdoc] Correctly check that an item is notdoc(hidden)with--generate-link-to-definition)r? @ghost
Create a similar rollup