| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove `NtExpr` and `NtLiteral`
The next part of #124141.
r? `@petrochenkov`
|
|
Currently it uses `walk_item` on some item kinds. For other item kinds
it visits the fields individually. For the latter group, this commit
adds `visit_attrs_vis` and `visit_attrs_vis_ident` which bundle up
visits to the fields that don't need special handling. This makes it
clearer that they haven't been forgotten about.
Also, it's better to do the attribute visits at the start because
attributes precede the items in the source code. Because of this, a
couple of tests have their output improved: errors appear in an order
that matches the source code order.
|
|
This makes the expression re-parsing more like how it's originally done
in `parse_nonterminal`.
|
|
|
|
Notes about tests:
- tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are
now duplicated due to repeated parsing.
- tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto.
- `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large
but the only difference is the insertion of a single
invisible-delimited group around a metavar.
- `tests/ui/attributes/nonterminal-expansion.rs`: a slight span
degradation, somehow related to the recent massive attr parsing
rewrite (#135726). I couldn't work out exactly what is going wrong,
but I don't think it's worth holding things up for a single slightly
suboptimal error message.
|
|
Feed HIR for by-move coroutine body def, since the inliner tries to read its attrs
See the comments in the test.
I'm surprised that nobody found this[^1] (edit: nvm haha), but you have to go out of your way to construct the by-move body and then inline it w/ a poll call, so I guess the inliner just never really gets into this situation before.
Fixes #134335
r? oli-obk
[^1]: Well, ````@eholk```` found this when working on the `iter! {}` macro, since it more dramatically affects those.
|
|
increment depth of nested obligations
properly fixes the root cause of #109268. While we didn't get hangs here before, I ended up encountering its root cause again with #138785.
r? types
|
|
Note potential but private items in show_candidates
Closes #138626 .
We should add potential private items to give ample hints.
And for the other seemingly false positive ` pub use crate::one::Foo;` should be kept because we don't know if the user wants to import other module's items or not, and therefore should be given the full option to do so.
r? compiler
|
|
|
|
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
|
|
|
|
Move `ast::Item::ident` into `ast::ItemKind`
The follow-up to #138384, which did the same thing for `hir::ItemKind`.
r? `@fmease`
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
`ast::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
`Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
`Trait`, `TraitAlias`, `MacroDef`, `Delegation`.
- It's always empty for these item kinds: `Use`, `ForeignMod`,
`GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`.
There is a similar story for `AssocItemKind` and `ForeignItemKind`.
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.
The commit is large but it's mostly obvious plumbing work. Some notable
things.
- `ast::Item` got 8 bytes bigger. This could be avoided by boxing the
fields within some of the `ast::ItemKind` variants (specifically:
`Struct`, `Union`, `Enum`). I might do that in a follow-up; this
commit is big enough already.
- For the visitors: `FnKind` no longer needs an `ident` field because
the `Fn` within how has one.
- In the parser, the `ItemInfo` typedef is no longer needed. It was used
in various places to return an `Ident` alongside an `ItemKind`, but
now the `Ident` (if present) is within the `ItemKind`.
- In a few places I renamed identifier variables called `name` (or
`foo_name`) as `ident` (or `foo_ident`), to better match the type, and
because `name` is normally used for `Symbol`s. It's confusing to see
something like `foo_name.name`.
|
|
`expand_test_case` looks for any item with a `#[test_case]` attribute
and adds a `test_path_symbol` attribute to it while also fiddling with
the item's ident's span.
This is pretty weird, because `#[test_case]` is only valid on
`fn`/`const`/`static` items, as far as I can tell. But you don't
currently get an error or warning if you use it on other kinds of items.
This commit changes things so that a `#[test_case]` item is modified
only if it is `fn`/`const`/`static`. This is relevant for moving idents
from `Item` to `ItemKind`, because some item kinds don't have an ident,
e.g. `impl` blocks.
The commit also does the following.
- Renames a local variable `test_id` as `test_ident`.
- Changes a `const` to `static` in
`tests/ui/custom_test_frameworks/full.rs` to give the `static` case
some test coverage.
- Adds a `struct` and `impl` to the same test to give some test coverage
to the non-affected item kinds. These have a `FIXME` comment
identifying the weirdness here. Hopefully this will be useful
breadcrumbs for somebody else in the future.
|
|
|
|
attrs
|
|
Remove fragile equal-pointers-unequal/*/print3.rs tests.
These tests were added in #127003
The print3.rs tests stop working when I change implementation details of format_args!(). (For example, in https://github.com/rust-lang/rust/pull/139175 and https://github.com/rust-lang/rust/pull/139135). These tests shouldn't rely on such implementation details. It gets in the way for format_args!() improvements.
If they test anything that aren't already covered by the other tests in this directory, they should be expressed in a less fragile way that doesn't rely on internal details of format_args!().
cc ``@GrigorenkoPV,`` author of these tests.
|
|
rustc_resolve: Test the order that preludes are resolved
This test is exhaustive. See attached truth table:
Companion PR to https://github.com/rust-lang/reference/pull/1765.
|
|
Rollup of 6 pull requests
Successful merges:
- #138176 (Prefer built-in sized impls (and only sized impls) for rigid types always)
- #138749 (Fix closure recovery for missing block when return type is specified)
- #138842 (Emit `unused_attributes` for `#[inline]` on exported functions)
- #139153 (Encode synthetic by-move coroutine body with a different `DefPathData`)
- #139157 (Remove mention of `exhaustive_patterns` from `never` docs)
- #139167 (Remove Amanieu from the libs review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
The former is just too long, see the examples in `hygiene.rs`
|
|
Encode synthetic by-move coroutine body with a different `DefPathData`
See the included test. In the first revision rpass1, we have an async closure `{closure#0}` which has a coroutine as a child `{closure#0}::{closure#0}`. We synthesize a by-move coroutine body, which is `{closure#0}::{closure#1}` which depends on the mir_built query, which depends on the typeck query.
In the second revision rpass2, we've replaced the coroutine-closure by a closure with two children closure. Notably, the def path of the second child closure is the same as the synthetic def id from the last revision: `{closure#0}::{closure#1}`. When type-checking this closure, we end up trying to compute its def_span, which tries to fetch it from the incremental cache; this will try to force the dependencies from the last run, which ends up forcing the mir_built query, which ends up forcing the typeck query, which ends up with a query cycle.
The problem here is that we really should never have used the same `DefPathData` for the synthetic by-move coroutine body, since it's not a closure. Changing the `DefPathData` will mean that we can see that the def ids are distinct, which means we won't try to look up the closure's def span from the incremental cache, which will properly skip replaying the node's dependencies and avoid a query cycle.
Fixes #139142
|
|
Emit `unused_attributes` for `#[inline]` on exported functions
I saw someone post a code sample that contained these two attributes, which immediately made me suspicious.
My suspicions were confirmed when I did a small test and checked the compiler source code to confirm that in these cases, `#[inline]` is indeed ignored (because you can't exactly `LocalCopy`an unmangled symbol since that would lead to duplicate symbols, and doing a mix of an unmangled `GloballyShared` and mangled `LocalCopy` instantiation is too complicated for our current instatiation mode logic, which I don't want to change right now).
So instead, emit the usual unused attribute lint with a message saying that the attribute is ignored in this position.
I think this is not 100% true, since I expect LLVM `inlinehint` to still be applied to such a function, but that's not why people use this attribute, they use it for the `LocalCopy` instantiation mode, where it doesn't work.
r? saethlin as the instantiation guy
Procedurally, I think this should be fine to merge without any lang involvement, as this only does a very minor extension to an existing lint.
|
|
Fix closure recovery for missing block when return type is specified
Firstly, fix the `is_array_like_block` condition to make sure we're actually recovering a mistyped *block* rather than some other delimited expression. This fixes #138748.
Secondly, split out the recovery of missing braces on a closure body into a separate recovery. Right now, the suggestion `"you might have meant to write this as part of a block"` originates from `suggest_fixes_misparsed_for_loop_head`, which feels kinda brittle and coincidental since AFAICT that recovery wasn't ever really intended to fix this.
We also can make this `MachineApplicable` in this case.
Fixes #138748
r? `@fmease` or reassign if you're busy/don't wanna review this
|
|
Prefer built-in sized impls (and only sized impls) for rigid types always
This PR changes the confirmation of `Sized` obligations to unconditionally prefer the built-in impl, even if it has nested obligations. This also changes all other built-in impls (namely, `Copy`/`Clone`/`DiscriminantKind`/`Pointee`) to *not* prefer built-in impls over param-env impls. This aligns the old solver with the behavior of the new solver.
---
In the old solver, we register many builtin candidates with the `BuiltinCandidate { has_nested: bool }` candidate kind. The precedence this candidate takes over other candidates is based on the `has_nested` field. We only prefer builtin impls over param-env candidates if `has_nested` is `false`
https://github.com/rust-lang/rust/blob/2b4694a69804f89ff9d47d1a427f72c876f7f44c/compiler/rustc_trait_selection/src/traits/select/mod.rs#L1804-L1866
Preferring param-env candidates when the builtin candidate has nested obligations *still* ends up leading to detrimental inference guidance, like:
```rust
fn hello<T>() where (T,): Sized {
let x: (_,) = Default::default();
// ^^ The `Sized` obligation on the variable infers `_ = T`.
let x: (i32,) = x;
// We error here, both a type mismatch and also b/c `T: Default` doesn't hold.
}
```
Therefore this PR adjusts the candidate precedence of `Sized` obligations by making them a distinct candidate kind and unconditionally preferring them over all other candidate kinds.
Special-casing `Sized` this way is necessary as there are a lot of traits with a `Sized` super-trait bound, so a `&'a str: From<T>` where-bound results in an elaborated `&'a str: Sized` bound. People tend to not add explicit where-clauses which overlap with builtin impls, so this tends to not be an issue for other traits.
We don't know of any tests/crates which need preference for other builtin traits. As this causes builtin impls to diverge from user-written impls we would like to minimize the affected traits. Otherwise e.g. moving impls for tuples to std by using variadic generics would be a breaking change. For other builtin impls it's also easier for the preference of builtin impls over where-bounds to result in issues.
---
There are two ways preferring builtin impls over where-bounds can be incorrect and undesirable:
- applying the builtin impl results in undesirable region constraints. E.g. if only `MyType<'static>` implements `Copy` then a goal like `(MyType<'a>,): Copy` would require `'a == 'static` so we must not prefer it over a `(MyType<'a>,): Copy` where-bound
- this is mostly not an issue for `Sized` as all `Sized` impls are builtin and don't add any region constraints not already required for the type to be well-formed
- however, even with `Sized` this is still an issue if a nested goal also gets proven via a where-bound: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=30377da5b8a88f654884ab4ebc72f52b)
- if the builtin impl has associated types, we should not prefer it over where-bounds when normalizing that associated type. This can result in normalization adding more region constraints than just proving trait bounds. https://github.com/rust-lang/rust/issues/133044
- not an issue for `Sized` as it doesn't have associated types.
r? lcnr
|
|
Revert "Rollup merge of #136127 - WaffleLapkin:dyn_ptr_unwrap_cast, r=compiler-errors"
...not permanently tho. Just until we can land something like #138542, which will fix the underlying perf issues (https://github.com/rust-lang/rust/pull/136127#issuecomment-2743891744). I just don't want this to land on beta and have people rely on this behavior if it'll need some reworking for it to be implemented performantly.
r? `@WaffleLapkin` or reassign -- sorry for reverting ur pr! i'm working on getting it re-landed soon :>
|
|
hygiene: Rewrite `apply_mark_internal` to be more understandable
The previous implementation allocated new `SyntaxContext`s in the inverted order, and it was generally very hard to understand why its result matches what the `opaque` and `opaque_and_semitransparent` field docs promise.
```rust
/// This context, but with all transparent and semi-transparent expansions filtered away.
opaque: SyntaxContext,
/// This context, but with all transparent expansions filtered away.
opaque_and_semitransparent: SyntaxContext,
```
It also couldn't be easily reused for the case where the context id is pre-reserved like in #129827.
The new implementation tries to follow the docs in a more straightforward way.
I did the transformation in small steps, so it indeed matches the old implementation, not just the docs.
So I suggest reading only the new version.
|
|
Uplift `clippy::invalid_null_ptr_usage` lint as `invalid_null_arguments`
This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](https://github.com/rust-lang/rust/pull/111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.
*For context: GitHub Search reveals that just for `slice::from_raw_parts{_mut}` [~20 invalid usages](hhttps://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%28_mut%29%3F%5C%28ptr%3A%3Anull%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F&type=code) with `ptr::null` and an additional [4 invalid usages](https://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%5C%280%28%5C%29%7C+as%29%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Ftinystr%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Fzerovec%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eprovider%5C%2Fcore%5C%2Fsrc%5C%2F%2F&type=code) with `0 as *const ...`-ish casts.*
-----
## `invalid_null_arguments`
(deny-by-default)
The `invalid_null_arguments` lint checks for invalid usage of null pointers.
### Example
```rust
// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 1); }
```
Produces:
```
error: calling this function with a null pointer is Undefined Behavior, even if the result of the function is unused
--> $DIR/invalid_null_args.rs:21:23
|
LL | let _: &[usize] = std::slice::from_raw_parts(ptr::null_mut(), 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------^^^^
| |
| null pointer originates from here
|
= help: for more information, visit <https://doc.rust-lang.org/std/ptr/index.html> and <https://doc.rust-lang.org/reference/behavior-considered-undefined.html>
```
### Explanation
Calling methods whose safety invariants requires non-null pointer with a null pointer is undefined behavior.
-----
The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute.
This PR also includes some small refactoring to avoid some ambiguities in naming, those can be done in another PR is desired.
`@rustbot` label: +I-lang-nominated
r? compiler
|
|
|
|
Remove attribute `#[rustc_error]`
It was an ancient way to write `check-pass` tests, but now it's no longer necessary (except for the `delayed_bug_from_inside_query` flavor, which is retained).
|
|
|
|
|
|
amy-kwan:amy-kwan/reprc-struct-power-align-ignore-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.
|
|
Revert "Auto merge of #129827 - bvanjoi:less-decoding, r=petrochenkov"
Reverting https://github.com/rust-lang/rust/pull/129827 because of a performance regression.
This reverts commit d4812c8638173ec163825d56a72a33589483ec4c, reversing changes made to 5cc60728e7ee10eb2ae5f61f7d412d9805b22f0c.
r? `@petrochenkov`
|
|
Reverting because of a performance regression.
This reverts commit d4812c8638173ec163825d56a72a33589483ec4c, reversing
changes made to 5cc60728e7ee10eb2ae5f61f7d412d9805b22f0c.
|
|
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](https://github.com/rust-lang/cc-rs/pull/1413) simpler.
Fixes https://github.com/rust-lang/rust/issues/131165.
CC target maintainer `@Itus-Shield`
|
|
|
|
param-env for receiver_is_dispatchable
|
|
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
|
|
|
|
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
|
|
|
|
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`.
|
|
Implement `alloc::sync::UniqueArc`
This implements the `alloc::sync::UniqueArc` part of #112566.
|
|
perform less decoding if it has the same syntax context
Following this [comment](https://github.com/rust-lang/rust/pull/127279#issuecomment-2210376603)
r? `@petrochenkov`
|
|
|
|
|
