Rollup of 9 pull requests #132621
Closed
Rollup of 9 pull requests #132621
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
Add a few more possibly false-positive tests for the `improper_ctypes` lint
Fixes rust-lang#126425 Replace the potentially panicking `[]` indexing with `get_unchecked()` to prevent linking with panic-related code.
The previous version used `['l', 'l']` as pattern, which would suggest that it matches the `ll` of `Hello world` as a whole.
…ler-errors Improve duplicate derive Copy/Clone diagnostics Improve duplicate derive Copy/Clone diagnostics. Closes rust-lang#131083
…rkingjubilee Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This basically does a similar thing I did in rust-lang#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces rust-lang#111335 and rust-lang#124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).
fix suggestion for diagnostic error E0027 Closes rust-lang#132008
…, r=dtolnay Stabilise `const_char_encode_utf16`. Closes: rust-lang#130660 This PR stabilises the `const_char_encode_utf16` feature gate (i.e. support for `char::encode_utf16` in constant expressions). ~~Note that the linked tracking issue is as of this writing currently awaiting FCP until 2024-11-02.~~
…ler-errors More tests for non-exhaustive C-like enums in FFI Add a few more tests for the `improper_ctypes` lint as found with the [varnish-rs](https://github.com/gquintard/varnish-rs) project. This follows up on rust-lang#116831, fixed in rust-lang#116863 by `@workingjubilee` - I have been seeing these fail with the bindgen-generated non-exhaustive enums inside other structs. Seems the issue does not exist in the primary branch, so this PR just makes sure more cases are covered for the future.
…joboet [core/fmt] Replace checked slice indexing by unchecked to support panic-free code Fixes rust-lang#126425 Replace the potentially panicking `[]` indexing with `get_unchecked()` to prevent linking with panic-related code.
…r=xFrednet Clippy: Move some attribute lints to be early pass (post expansion) r? ``@xFrednet`` As a side effect it removes a duplicated warning on line 53 of the `allow_attributes` test. I discussed this with ``@xFrednet`` , and it's mainly to support the attribute rework rust-lang#131229
…oc, r=tgross35 Improve example of `impl Pattern for &[char]` The previous version used `['l', 'l']` as pattern, which would suggest that it matches the `ll` of `Hello world` as a whole.
docs: fix grammar in doc comment at unix/process.rs Fixed the grammar of a sentence in the docs
rustbot
added
O-unix
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 5, 2024
Rollup of 9 pull requests Successful merges: - rust-lang#131153 (Improve duplicate derive Copy/Clone diagnostics) - rust-lang#131341 (Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly) - rust-lang#132025 (fix suggestion for diagnostic error E0027) - rust-lang#132153 (Stabilise `const_char_encode_utf16`.) - rust-lang#132303 (More tests for non-exhaustive C-like enums in FFI) - rust-lang#132473 ([core/fmt] Replace checked slice indexing by unchecked to support panic-free code) - rust-lang#132598 (Clippy: Move some attribute lints to be early pass (post expansion)) - rust-lang#132606 (Improve example of `impl Pattern for &[char]`) - rust-lang#132609 (docs: fix grammar in doc comment at unix/process.rs) r? `@ghost` `@rustbot` modify labels: rollup
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
workingjubilee
added
the
CI-spurious-fail-msvc
|
@bors retry |
bors
added
S-waiting-on-bors
|
Superseded by #132626 |
|
specifically, #131341 entered the queue independently. |
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.
Successful merges:
const_char_encode_utf16. #132153 (Stabiliseconst_char_encode_utf16.)impl Pattern for &[char]#132606 (Improve example ofimpl Pattern for &[char])r? @ghost
@rustbot modify labels: rollup
Create a similar rollup