Rustc pull update #2291
Open
Rustc pull update #2291
+50
−12
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Move `hir::Item::ident` into `hir::ItemKind`.
`hir::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Macro`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, Trait`, TraitAalis`.
- It's always empty for these item kinds: `ForeignMod`, `GlobalAsm`, `Impl`.
- For `Use`, it is non-empty for `UseKind::Single` and empty for `UseKind::{Glob,ListStem}`.
All of this is quite non-obvious; the only documentation is a single comment saying "The name might be a dummy name in case of anonymous items". Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out.
This is step towards `kw::Empty` elimination (#137978).
r? `@fmease`
Clarify "owned data" in E0515.md This clarifies the explanation of why this is not allowed and also what to do instead. Fixes #62071 PS There was suggestion of adding a link to the book. I did not yet do that, but if desired that could be added.
Store test diffs in job summaries and improve analysis formatting This PR stores the test diffs that we already have in the post-merge workflow also into individual job summaries. This makes it easier to compare test (and later also other) diffs per job, which will be especially useful for try jobs, so that we can actually see the test diffs *before* we merge a given PR. As a drive-by, I also made a bunch of cleanups in `citool` and in the formatting of the summary and post-merge analyses. These changes are split into self-contained commits. The analysis can be tested locally with the following command: ```bash $ curl https://ci-artifacts.rust-lang.org/rustc-builds/<current-sha>/metrics-<job-name>.json > metrics.json $ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name <job-name> --parent <parent-sha> > out.md ``` For example, for [this PR](rust-lang/rust#138523): ```bash $ curl https://ci-artifacts.rust-lang.org/rustc-builds/282865097d138c7f0f7a7566db5b761312dd145c/metrics-aarch64-gnu.json > metrics.json $ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name aarch64-gnu --parent d9e5539a39192028a7b15ae596a8685017faecee > out.md ``` Best reviewed commit by commit. r? `@marcoieni` try-job: aarch64-gnu try-job: dist-x86_64-linux
Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly Some CI jobs (x64 Linux, ARM64 Linux and x64 MSVC) use the `opt-dist` tool to build an optimized toolchain using PGO and BOLT. When performing a default try build for x64 Linux, in most cases we want to run perf. on that artifact. To reduce the latency of this common use-case, `opt-dist` skips building several components not needed for perf., and it also skips running post-optimization tests, when it detects that the job is executed as a try job (not a merge/auto job). This is useful, but it also means that if you *want* to run the tests, you had to go to `jobs.yml` and manually comment this environment variable, create a WIP commit, do a try build, and then remove the WIP commit, which is annoying (in the similar way that modifying what gets run in try builds was annoying before we had the `try-job` annotations). I thought that we could introduce some additional PR description marker like `try-job-run-tests`, but it's hard to discover that such things exist. Instead, I think that there's a much simpler heuristic for determining whether `DIST_TRY_BUILD` should be used (that I implemented in this PR): - If you do just ``@bors` try`, without any custom try jobs selected, `DIST_TRY_BUILD` will be activated, to finish the build as fast as possible. - If you specify any custom try jobs, you are most likely doing experiments and you want to see if tests pass and everything builds as it should. The `DIST_TRY_BUILD` variable will thus *not* be set in this case. In this way, if you want to run dist tests, you can just add the `try-job: dist-x86_64-linux` line to the PR description, and you don't need to create any WIP commits. r? `@marcoieni`
…laumeGomez,Urgau Fix ICE: attempted to remap an already remapped filename This commit fixes an internal compiler error (ICE) that occurs when rustdoc attempts to process macros with a remapped filename. The issue arose during macro expansion when the `--remap-path-prefix` option was used. Instead of passing remapped filenames through, which would trigger the "attempted to remap an already remapped filename" panic, we now extract the original local path from remapped filenames before processing them. A test case has been added to verify this behavior. Fixes #138520
rustc_target: Add target feature constraints for LoongArch Part of rust-lang/rust#116344 r? `@RalfJung`
Flatten `if`s in `rustc_codegen_ssa` Best viewed [while ignoring whitespace](https://github.com/rust-lang/rust/pull/138619/files?diff=unified&w=1)
Rollup of 7 pull requests Successful merges: - #138384 (Move `hir::Item::ident` into `hir::ItemKind`.) - #138508 (Clarify "owned data" in E0515.md) - #138531 (Store test diffs in job summaries and improve analysis formatting) - #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly) - #138556 (Fix ICE: attempted to remap an already remapped filename) - #138608 (rustc_target: Add target feature constraints for LoongArch) - #138619 (Flatten `if`s in `rustc_codegen_ssa`) r? `@ghost` `@rustbot` modify labels: rollup
uefi: fs: Implement exists Also adds the initial file abstractions. The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol. After that, it queries all handles supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat. It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently. DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators. This is an effort to break the original PR (rust-lang/rust#129700) into much smaller chunks for faster upstreaming.
Temporarily disable Fuchsia test job to unblock queue See <https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259> for efforts to fix the test job. This PR temporarily disables the Fuchsia test job to unblock the queue, so that neither the Fuchsia maintainers nor T-infra maintainers should feel pressured to fix the job ASAP. Please feel free to re-enable once the test job is fixed. FYI `@erickt` since you or other Fuchsia maintainers will need to revert this change to merge Fuchsia test job fixes in the future. r? infra-ci
clarify BufRead::{fill_buf, consume} docs
Fixes #85394
Remove the regex dependency from coretests It is only used by a single test, yet would take up unnecessary space once stdlib deps get vendored.
rustc-dev-guide sync r? `@jieyouxu`
Remove double nesting in post-merge workflow See [this](rust-lang/rust#138630 (comment)) :) Can be tested with: ```bash #!/bin/bash PARENT_COMMIT=493c38ba371929579fe136df26eccd9516347c7a SHA=259fdb521200c9abba547302fc2c826479ef26b2 printf "<details>\n<summary>What is this?</summary>\n" >> output.log printf "This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.\n" >> output.log printf "</details>\n\n" >> output.log cargo run --release post-merge-report ${PARENT_COMMIT} ${SHA} >> output.log ``` I think that it's better to leave the notice in CI, to avoid generating it in citool, which can also be executed locally. r? `@marcoieni`
CI: mirror alpine and centos images to ghcr
coverage: Don't store a body span in `FunctionCoverageInfo` We aren't using this body span for anything truly essential, and having it around will be awkward when we eventually start to support expansion regions, since they aren't necessarily within the main body.
…chenkov Revert: Add *_value methods to proc_macro lib This reverts rust-lang/rust#136355. That PR caused unexpected breakage: - the rustc-dev component can no longer be loaded by cargo, which impacts Miri and clippy and likely others - rustc_lexer can no longer be published to crates.io, which impacts RA See rust-lang/rust#138647 for context. Cc `@GuillaumeGomez` `@Amanieu`
Remove existing AFIDT implementation This experiment will need to be reworked differently; I don't think we'll be going with the `dyn* Future` approach that is currently implemented. r? oli-obk Fixes #136286 Fixes #137706 Fixes #137895 Tracking: * #133119
Various codegen_llvm cleanups Mostly just adding safe wrappers and deduplicating code
use then in docs for `fuse` to enhance readability
use the more-idiomatic `then_some` rather than an `if { some } else { none }` for `fused` docs
Rollup of 10 pull requests
Successful merges:
- #136177 (clarify BufRead::{fill_buf, consume} docs)
- #138654 (Remove the regex dependency from coretests)
- #138655 (rustc-dev-guide sync)
- #138656 (Remove double nesting in post-merge workflow)
- #138658 (CI: mirror alpine and centos images to ghcr)
- #138659 (coverage: Don't store a body span in `FunctionCoverageInfo`)
- #138661 (Revert: Add *_value methods to proc_macro lib)
- #138670 (Remove existing AFIDT implementation)
- #138674 (Various codegen_llvm cleanups)
- #138684 (use then in docs for `fuse` to enhance readability)
r? `@ghost`
`@rustbot` modify labels: rollup
Represent diagnostic side effects as dep nodes This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index. Some implications of this: - Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that. - Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks. - Reusing a CGU will now emit diagnostics from the task generating it.
…-19, r=workingjubilee Portable SIMD subtree update
github-actions
bot
force-pushed
the
rustc-pull
branch
from
9d4b933 to
a3e1c32
Compare
Update to LLVM 20.1.1 Fixes rust-lang/rust#138212. Fixes rust-lang/rust#137909.
Consider fields to be inhabited if they are unstable Fixes #133885 with a simple heuristic r? Nadrieril Not totally certain if this needs T-lang approval or a crater run.
…er-errors Remove InstanceKind::generates_cgu_internal_copy This PR should not contain any behavior changes. Before this PR, the logic for selecting instantiation mode is spread across all of * `instantiation_mode` * `cross_crate_inlinable` * `generates_cgu_internal_copy` * `requires_inline` The last two of those functions are not well-designed. The function that actually decides if we generate a CGU-internal copy is `instantiation_mode`, _not_ `generates_cgu_internal_copy`. The function `requires_inline` documents that it is about the LLVM `inline` attribute and that it is a hint. The LLVM attribute is called `inlinehint`, this function is also used by other codegen backends, and since it is part of instantiation mode selection it is *not* a hint. The goal of this PR is to start cleaning up the logic into a sequence of checks that have a more logical flow and are easier to customize in the future (to do things like improve incrementality or improve optimizations without causing obscure linker errors because you forgot to update another part of the compiler).
compiletest: Support matching on diagnostics without a span Using `//~? ERROR my message` on any line of the test. The new checks are exhaustive, like all other `//~` checks, and unlike the `error-pattern` directive that is sometimes used now to check for span-less diagnostics. This will allow to eliminate most on `error-pattern` directives in compile-fail tests (except those that are intentionally imprecise due to platform-specific diagnostics). I didn't migrate any of `error-pattern`s in this PR though, except those where the migration was necessary for the tests to pass.
Rollup of 8 pull requests Successful merges: - #135745 (Recognise new IPv6 non-global range from IETF RFC 9602) - #137247 (cg_llvm: Reduce the visibility of types, modules and using declarations in `rustc_codegen_llvm`.) - #138317 (privacy: Visit types and traits in impls in type privacy lints) - #138581 (Abort in deadlock handler if we fail to get a query map) - #138776 (coverage: Separate span-extraction from unexpansion) - #138886 (Fix autofix for `self` and `self as …` in `unused_imports` lint) - #138924 (Reduce `kw::Empty` usage, part 3) - #138929 (Visitors track whether an assoc item is in a trait impl or an inherent impl) r? `@ghost` `@rustbot` modify labels: rollup
add FCW to warn about wasm ABI transition See rust-lang/rust#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following: - scalar arguments are fine - including 128 bit types, they get passed as two `i64` arguments in both ABIs - `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes) - all return values are fine `@bjorn3` `@alexcrichton` `@Manishearth` is that correct? I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this? IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments. Tracking issue: rust-lang/rust#138762 Transition plan blog post: rust-lang/blog.rust-lang.org#1531 try-job: dist-various-2
bump thorin to 0.9 to drop duped deps
Bumps `thorin`, removing duped deps.
This also changes features for hashbrown:
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
to
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "allocator-api2"
| `-- hashbrown feature "default"
|-- hashbrown feature "default" (*)
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "equivalent"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "inline-more"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
|-- hashbrown feature "raw-entry"
| `-- hashbrown feature "default" (*)
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
To be safe, as this can be perf-sensitive:
`@bors` rollup=never
hygiene: Ensure uniqueness of `SyntaxContextData`s `SyntaxContextData`s are basically interned with `SyntaxContext`s working as indices, so they are supposed to be unique. However, currently duplicate `SyntaxContextData`s can be created during decoding from metadata or incremental cache. This PR fixes that. cc rust-lang/rust#129827 (comment)
Remove `prev_index_to_index` field from `CurrentDepGraph` The dep graph currently has 2 ways to map a previous index into a current index. The `prev_index_to_index` map stores the current index equivalent of a previous index. For indices which are marked green, we also store the same information in the `DepNodeColorMap`. We actually only need to known the mapping for green nodes however, so this PR removes `prev_index_to_index` and instead makes use of the `DepNodeColorMap`. To avoid racing when promoting a node from the previous session, the encoder lock is now used to ensure only one thread encodes the promoted node. This was previously done by the lock in `prev_index_to_index`. This also changes `nodes_newly_allocated_in_current_session` used to detect duplicate dep nodes to contain both new and previous nodes, which is simpler and can better catch duplicates. The dep node index encoding used in `DepNodeColorMap` is tweak to avoid subtraction / addition to optimize accessing the current equivalent of a previous index. r? `@oli-obk`
github-actions
bot
force-pushed
the
rustc-pull
branch
from
8276d2a to
b0fe733
Compare
Instantiate binder before registering nested obligations for auto/built-in traits Instead of turning a `Binder<Vec<Ty>>` into a bunch of higher-ranked predicates, instantiate the binder eagerly *once* and turn them into a bunch of non-higher-ranked predicates. Right now this feels like a noop, but this `enter_forall_and_leak_universe` call would be the singular place where we could instantiate bound lifetime assumptions for coroutine witnesses... if we had them. Thus consolidating the binder instantiation here is useful if we want to fix the coroutine-auto-trait problem. r? lcnr
…aumeGomez rustdoc: Rearrange `Item`/`ItemInner`. The `Item` struct is 48 bytes and contains a `Box<ItemInner>`; `ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd have one of the following. - A single large struct, which avoids the allocation for the `Box`, but can result in lots of wasted space in unused parts of a container like `Vec<Item>`, `HashSet<Item>`, etc. - Or, something like `struct Item(Box<ItemInner>)`, which requires the `Box` allocation but gives a very small Item size, which is good for containers like `Vec<Item>`. `Item`/`ItemInner` currently gets the worst of both worlds: it always requires a `Box`, but `Item` is also pretty big and so wastes space in containers. It would make sense to push it in one direction or the other. #138916 showed that the first option is a regression for rustdoc, so this commit does the second option, which improves speed and reduces memory usage. r? `@GuillaumeGomez`
Allow spawning threads after TLS destruction Fixes #138696
Avoid wrapping constant allocations in packed structs when not necessary This way LLVM will set the string merging flag if the alloc is a nul terminated string, reducing binary sizes. try-job: armhf-gnu
Implement `alloc::sync::UniqueArc` This implements the `alloc::sync::UniqueArc` part of #112566.
stabilize const_cell ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval`` I see no reason to wait any longer, so I propose we stabilize the use of `Cell` in `const fn` -- specifically the APIs listed here: ```rust // core::cell impl<T> Cell<T> { pub const fn replace(&self, val: T) -> T; } impl<T: Copy> Cell<T> { pub const fn get(&self) -> T; } impl<T: ?Sized> Cell<T> { pub const fn get_mut(&mut self) -> &mut T; pub const fn from_mut(t: &mut T) -> &Cell<T>; } impl<T> Cell<[T]> { pub const fn as_slice_of_cells(&self) -> &[Cell<T>]; } ``` Unfortunately, `set` cannot be made `const fn` yet as it drops the old contents. Fixes rust-lang/rust#131283
Fix `uclibc` LLVM target triples `uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag). In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead. Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct. **There are no target maintainers for these targets.** So I'll CC ``@lancethepants`` and ``@skrap`` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights. r? jieyouxu
Start using `with_native_path` in `std::sys::fs` Ideally, each platform should use their own native path type internally. This will, for example, allow passing a `CStr` directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated C string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this PR does some minimal refactoring which should help progress towards that goal. The changes are Unix-only and even then I avoided functions that require more changes so that this PR is just moving things around. r? joboet
compiletest: Support matching diagnostics on lines below Using `//~vvv ERROR`. This is not needed often, but it's easy to support, and it allows to eliminate a class of `error-pattern`s that cannot be eliminated in any other way. See the diff for the examples of such patterns coming from parser. Some of them can be matched by `//~ ERROR` or `//~^ ERROR` as well (when the final newline is allowed), but it changes the shape of reported spans, so I chose to keep the spans by using `//~v ERROR`.
…rors `BackendRepr::is_signed`: comment why this may panics Was wondering why this method could panics while the others couldn't, so quote PR #70189.
Mark .pp files as Rust Pretty-printing tests generate `.pp` files, but GitHub classify and highlight them as Pascal: [https://github.com/search?q=repo:rust-lang/rust+path:*.pp&type=code](https://github.com/search?q=repo%3Arust-lang%2Frust+path%3A*.pp&type=code) ``@rustbot`` label +A-meta +A-testsuite
Rollup of 7 pull requests Successful merges: - #137928 (stabilize const_cell) - #138431 (Fix `uclibc` LLVM target triples) - #138832 (Start using `with_native_path` in `std::sys::fs`) - #139081 (std: deduplicate `errno` accesses) - #139100 (compiletest: Support matching diagnostics on lines below) - #139105 (`BackendRepr::is_signed`: comment why this may panics) - #139106 (Mark .pp files as Rust) r? `@ghost` `@rustbot` modify labels: rollup
rustc_target: Add more RISC-V vector-related features and use zvl*b target features in vector ABI check Currently, we have only unstable `v` target feature, but RISC-V have more vector-related extensions. The first commit of this PR adds them to unstable `riscv_target_feature`. - `unaligned-vector-mem`: Has reasonably performant unaligned vector - [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L1379) - Similar to currently unstable `unaligned-scalar-mem` target feature, but for vector instructions. - `zvfh`: Vector Extension for Half-Precision Floating-Point - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvfh-vector-extension-for-half-precision-floating-point) - [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L668) - This implies `zvfhmin` and `zfhmin` - `zvfhmin`: Vector Extension for Minimal Half-Precision Floating-Point - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvfhmin-vector-extension-for-minimal-half-precision-floating-point) - [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L662) - This implies `zve32f` - `zve32x`, `zve32f`, `zve64x`, `zve64f`, `zve64d`: Vector Extensions for Embedded Processors - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zve-vector-extensions-for-embedded-processors) - [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L612-L641) - `zve32x` implies `zvl32b` - `zve32f` implies `zve32x` and `f` - `zve64x` implies `zve32x` and `zvl64b` - `zve64f` implies `zve32f` and `zve64x` - `zve64d` implies `zve64f` and `d` - `v` implies `zve64d` - `zvl*b`: Minimum Vector Length Standard Extensions - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvl-minimum-vector-length-standard-extensions) - [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L600-L610) - `zvl{N}b` implies `zvl{N>>1}b` - `v` implies `zvl128b` - Vector Cryptography and Bit-manipulation Extensions - [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/vector-crypto.adoc) - [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L679-L807) - `zvkb`: Vector Bit-manipulation used in Cryptography - This implies `zve32x` - `zvbb`: Vector basic bit-manipulation instructions - This implies `zvkb` - `zvbc`: Vector Carryless Multiplication - This implies `zve64x` - `zvkg`: Vector GCM instructions for Cryptography - This implies `zve32x` - `zvkned`: Vector AES Encryption & Decryption (Single Round) - This implies `zve32x` - `zvknha`: Vector SHA-2 (SHA-256 only)) - This implies `zve32x` - `zvknhb`: Vector SHA-2 (SHA-256 and SHA-512) - This implies `zve64x` - This is superset of `zvknha`, but doesn't imply that feature at least in LLVM - `zvksed`: SM4 Block Cipher Instructions - This implies `zve32x` - `zvksh`: SM3 Hash Function Instructions - This implies `zve32x` - `zvkt`: Vector Data-Independent Execution Latency - Similar to already stabilized scalar cryptography extension `zkt`. - `zvkn`: Shorthand for 'Zvkned', 'Zvknhb', 'Zvkb', and 'Zvkt' - Similar to already stabilized scalar cryptography extension `zkn`. - `zvknc`: Shorthand for 'Zvkn' and 'Zvbc' - `zvkng`: shorthand for 'Zvkn' and 'Zvkg' - `zvks`: shorthand for 'Zvksed', 'Zvksh', 'Zvkb', and 'Zvkt' - Similar to already stabilized scalar cryptography extension `zks`. - `zvksc`: shorthand for 'Zvks' and 'Zvbc' - `zvksg`: shorthand for 'Zvks' and 'Zvkg' Also, our vector ABI check wants `zvl*b` target features, the second commit of this PR updates vector ABI check to use them. https://github.com/rust-lang/rust/blob/4e2b096ed6c8a1400624a54f6c4fd0c0ce48a579/compiler/rustc_target/src/target_features.rs#L707-L708 --- r? `@Amanieu` `@rustbot` label +O-riscv +A-target-feature
Set `target_vendor = "openwrt"` on `mips64-openwrt-linux-musl` OpenWRT is a Linux distribution for embedded network devices. The target name contains `openwrt`, so we should set `cfg(target_vendor = "openwrt")`. This is similar to what other Linux distributions do (the only one in-tree is `x86_64-unikraft-linux-musl`, but that sets `target_vendor = "unikraft"`). Motivation: To make correctly [parsing target names](rust-lang/cc-rs#1413) simpler. Fixes rust-lang/rust#131165. CC target maintainer `@Itus-Shield`
…nore-packed-align, r=workingjubilee [AIX] Ignore linting on repr(C) structs with repr(packed) or repr(align(n)) This PR updates the lint added in 9b40bd7 to ignore repr(C) structs that also have repr(packed) or repr(align(n)). As these representations can be modifiers on repr(C), it is assumed that users that add these should know what they are doing, and thus the the lint should not warn on the respective structs. For example, for the time being, using repr(packed) and manually padding a repr(C) struct can be done to correctly align struct members on AIX.
…acrum
Simplify expansion for format_args!().
Instead of calling `Placeholder::new()`, we can just use a struct expression directly.
Before:
```rust
Placeholder::new(…, …, …, …)
```
After:
```rust
Placeholder {
position: …,
flags: …,
width: …,
precision: …,
}
```
(I originally avoided the struct expression, because `Placeholder` had a lot of fields. But now that rust-lang/rust#136974 is merged, it only has four fields left.)
This will make the `fmt` argument to `fmt::Arguments::new_v1_formatted()` a candidate for const promotion, which is important if we ever hope to tackle rust-lang/rust#92698 (It doesn't change anything yet though, because the `args` argument to `fmt::Arguments::new_v1_formatted()` is not const-promotable.)
github-actions
bot
force-pushed
the
rustc-pull
branch
from
b0fe733 to
07c9abc
Compare
Merged
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.
Latest update from rustc.