-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 9 pull requests #139940
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 9 pull requests #139940
Conversation
Previously (rust-lang#115200, rust-lang#138002), we added `#[no_sanitize(cfi)]` to all code paths that call to a weakly linked function. In rust-lang#138349 we fixed the root cause for this issue, which means we can now remove the corresponding attributes.
Namely, use a more sensical primary span. Don't pretty-print AST nodes for the diagnostic message. Why: * It's lossy (e.g., it doesn't replicate trailing `+`s in trait objects. * It's prone to leak error nodes (printed as `(/*ERROR*/)`) since the LHS can easily represent recovered code (e.g., `fn(i32?) + T`).
also add `explicit-extern-abis` feature section to the unstable book.
This commit adds unprivileged ratified extensions that are either dicoverable from the `riscv_hwprobe` syscall of the Linux kernel (as of version 6.14) plus 1 minus 3 extensions. Plus 1: * "B" This is a combination of "Zba", "Zbb" and "Zbs". Note: Although not required by the RISC-V specification, it is convenient to imply "B" from its three members (will be implemented in LLVM 21/22) but this is not yet implemented in Rust due to current implication handling. It still implies three members *from* "B". Minus 2: * "Zcf" (target_arch = "riscv32" only) This is the compression instruction subset corresponding "F". This is implied from RV32 + "C" + "F" but this complex handling is not yet supported by Rust's feature handling. * "Zcd" This is the compression instruction subset corresponding "D". This is implied from "C" + "D" but this complex handling is not yet supported by Rust's feature handling. * "Supm" Unlike regular RISC-V extensions, "Supm" and "Sspm" extensions do not provide any specific architectural features / constraints but requires *some* mechanisms to control pointer masking for the current mode. For instance, reported existence of the "Supm" extension in Linux means that `prctl` system call to control pointer masking is available and there are alternative ways to detect the existence. Notes: * Because this commit adds the "Zca" extension (an integer subset of the "C" extension), the "C" extension is modified to imply "Zca".
The "B" extension is ratified as a combination of three extensions: "Zba", "Zbb" and "Zbs". To maximize discoverability of the RISC-V target features, this commit makes use of the "B" extension instead of its three members. This way, `#[cfg(target_feature = "b")]` can also be used instead of: `#[cfg(all(target_feature = "zba", target_feature = "zbb", target_feature = "zbs"))]`
…iscross,nadrieril Add `explicit_extern_abis` Feature and Enforce Explicit ABIs The unstable `explicit_extern_abis` feature is introduced, requiring explicit ABIs in `extern` blocks. Hard errors will be enforced with this feature enabled in a future edition. RFC rust-lang/rfcs#3722 Update rust-lang#134986
…2, r=Amanieu rustc_target: RISC-V: feature addition batch 2 Of ratified RISC-V extensions, this commit adds ones satisfying following criteria: 1. Either discoverable through a `riscv_hwprobe` system call on Linux 6.14 or should be very helpful even on basic needs (the `B` extension), 2. Does not disrupt current Rust's feature handling mechanism and 3. Not too OS-dependent (the `Supm` extension) Due to 2., the author excluded `Zcf` (RV32 only) and `Zcd` from the list despite that they are discoverable from Linux 6.14. Due to 3., the author excluded the `Supm` extension on the PR version 2. This is based on the specification: * [The latest ratified ISA Manuals (version 20240411)](https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications) Linux Definition: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/include/uapi/asm/hwprobe.h LLVM Definitions: * [`B`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L507-L510) * [`Zca`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L395-L398) * [`Zcb`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L407-L410) * [`Zcmop`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L460-L463) * [`Zfa`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L335-L338) * [`Zicboz`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L89-L92) * [`Zicond`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L125-L128) * [`Zihintntl`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L148-L151) * [`Zimop`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L161-L162) * [`Ztso`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L214-L217) The author also adds required implication: `C` implies `Zca`. Android RISC-V target is also updated to include the `B` extension (this is just a shorthand combination of `Zba`, `Zbb` and `Zbs` extensions but possibly simplifies `target_feature` handling). # History ## Version 1 → 2 * Remove the `Supm` extension from the Rust target features (thanks, `@Amanieu).` -------- Related: * rust-lang#44839 (`riscv_target_feature`) * rust-lang#138823 (my previous batch) * rust-lang#132618 (stabilization of the `Zfa` extension is blocked by this) `@rustbot` r? `@Amanieu` `@rustbot` label +T-compiler +O-riscv +A-target-feature
cfi: Remove #[no_sanitize(cfi)] for extern weak functions Previously (rust-lang#115200, rust-lang#138002), we added `#[no_sanitize(cfi)]` to all code paths that call to a weakly linked function. In rust-lang#138349 we fixed the root cause for this issue, which means we can now remove the corresponding attributes. r? `@rcvalle`
Don't require rigid alias's trait to hold See test for write-up. TL;DR is that we don't need the trait bound to hold, since we enforce it during WF. I think this is preferable to introducing (if we even could do so) a more specific hack around coroutine interiors, higher ranked types, etc, since this is just a manifestation of more pervasive issues w/ lifetime erasure in coroutines. This just doesn't manifest in the old solver b/c it doesn't try to prove `T: Trait` holds when rigidly projecting `<T as Trait>::Assoc`. It's pretty clear that this affects quite a few traits (rust-lang#139763), so I think this needs fixing. r? lcnr Fixes rust-lang/trait-system-refactor-initiative#177
…=davidtwco Improve parse errors for stray lifetimes in type position While technically & syntactically speaking lifetimes do begin[^1] types in type contexts (this essentially excludes generic argument lists) and require a following `+` to form a complete type (`'a +` denotes a bare trait object type), the likelihood that a user meant to write a lifetime-prefixed bare trait object type in *modern* editions (Rust ≥2021) when placing a lifetime into a type context is incredibly low (they would need to add at least three tokens to turn it into a *semantically* well-formed TOT: `'a` → `dyn 'a + Trait`). Therefore let's *lie* in modern editions (just like in PR rust-lang#131239, a precedent if you will) by stating "*expected type, found lifetime*" in such cases which is a lot more a approachable, digestible and friendly compared to "*lifetime in trait object type must be followed by `+`*" (as added in PR rust-lang#69760). I've also added recovery for "ampersand-less" reference types (e.g., `'a ()`, `'a mut Ty`) in modern editions because it was trivial to do and I think it's not unlikely to occur in practice. Fixes rust-lang#133413. [^1]: For example, in the context of decl macros, this implies that a lone `'a` always matches syntax fragment `ty` ("even if" there's a later macro matcher expecting syntax fragment `lifetime`). Rephrased, lifetimes (in type contexts) *commit* to the type parser.
… r=jieyouxu Clean UI tests 3 of n Cleaned up 2 tests in `tests/ui/numbers-arithemetic` to be more useful. One for each commit. I can squash these into one commit when approved. Related Issues: rust-lang#73494 rust-lang#133895 r? jieyouxu
Fix `opt-dist` CLI flag and make it work without LLD Suggested in https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/experiment.20with.20.60opt-dist.20local.60.20in.20MSYS2/with/512456991. r? `@jieyouxu`
…productive, r=compiler-errors stepping into impls for normalization is unproductive See the inline comment. This builds on the reasoning from rust-lang#136824 (https://gist.github.com/lcnr/c49d887bbd34f5d05c36d1cf7a1bf5a5). Fixes rust-lang/trait-system-refactor-initiative#176. Looking at the end of the gist: > The only ways to project out of a constructor are the following: > - accessing an associated item, either its type or its item bounds > - accessing super predicates Detecting cases where we accessing the type of an associated item is easy, it's simply when we normalize. I don't yet know how to detect whether we step out of an impl by accessing item bounds. Once we also detect these cases we should be able to soundly support arbitrary coinductive traits. Luckily this does not matter for this PR :> r? `@compiler-errors` cc `@nikomatsakis`
…iler-errors replace some #[rustc_intrinsic] usage with use of the libcore declarations Better to centralize the `#[rustc_intrinsic]` declarations in libcore than have them spread across the test suite as well.
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
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 79a272c (parent) -> 15c4cce (this PR) Test differencesShow 43 test diffsStage 1
Stage 2
Additionally, 2 doctest diffs were found. These are ignored, as they are noisy. Job group index
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: 79a272c640 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (15c4cce): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.2%, secondary -2.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.
CyclesResults (primary -0.3%)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.538s -> 775.789s (0.29%) |
Successful merges:
explicit_extern_abis
Feature and Enforce Explicit ABIs #135340 (Addexplicit_extern_abis
Feature and Enforce Explicit ABIs)opt-dist
CLI flag and make it work without LLD #139894 (Fixopt-dist
CLI flag and make it work without LLD)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup