This PR has started as an effort to proceed from the feedback in
rust-lang/rust-clippy#12861.
- Checks test functions (functions marked with `#[test]` annotation) for
redundant "test_" prefix.
- Auto-fix is supported (and handles collisions gracefully, see below).
- If removing "test_" prefix from, say, `test_foo()` results in a name
collision (either because function `foo()` is already defined within the
current scope, or because the `foo()` call exists within function --
thus creating an unwanted recursion), lint suggests function rename,
warning the user that a simple trimming of `test_` prefix will result in
a name collision.
- If removing "test_" prefix results in invalid identifier (consider
`test_const`, `test_`, `test_42`), then again no auto-fix is suggested,
user is asked to rename function, with a note that a simple prefix
trimming will result in an invalid function name.
(`Applicability::HasPlaceholders` is used and user is suggested to: drop
`test_` prefix + add `_works` suffix, i.e. `test_foo` becomes
`foo_works` -- but again, user has to apply those changes manually).
- If trimmed version of the function name is a valid identifier, doesn't
result in name collision or unwanted recursion, then user is able to run
auto-fix.
fixesrust-lang/rust-clippy#8931
changelog: new lint: [`redundant_test_prefix`]
`#[target_feature]` attributes refer to a target-specific list of
features. Enabling certain features can imply enabling other features.
Certain features are always enabled on certain targets, since they are
required by the target's ABI. Features can also be enabled indirectly
based on other compiler flags.
Feature information is ultimately known to `rustc`. Rather than force
external tools to track it -- which may be wildly impractical due to
`-C target-cpu` -- have `rustdoc` output `rustc`'s feature data.
Split `TypeFolder` and `FallibleTypeFolder` atwain
Right now there is a coherence problem with `TypeFolder` and `FallibleTypeFolder`. Namely, it's impossible to implement a `FallibleTypeFolder` that is generic over interner, b/c it has a *downstream* conflict with the blanket impl:
```
impl<I, F> FallibleTypeFolder<I> for F where F: TypeFolder<I> {}
```
Because downstream crates may implement `TypeFolder<SomeLocalInterner>` for the fallible type folder.
This PR removes the relationship between `FallibleTypeFolder` and `TypeFolder`; it leads to *modest* code duplication, but otherwise does not affect perf and really doesn't matter in general.
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"))]`
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".
Until in-kernel feature detection is implemented, runtime detection of
privileged extensions is temporally removed along with features themselves
since none of such privileged features are stable.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
Co-Authored-By: Amanieu d'Antras <amanieu@gmail.com>
This commit implements `riscv_hwprobe`-based feature detection as available
on newer versions of the Linux kernel. It also queries whether the vector
extensions are enabled using `prctl` but this is not supported on QEMU's
userland emulator (as of version 9.2.3) and use the auxiliary vector
as a fallback.
Currently, all extensions discoverable from the Linux kernel version 6.14
and related extension groups (except "Supm", which reports the existence of
`prctl`-based pointer masking control and too OS-dependent) are implemented.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
This commit adds the OS-independent extension implication logic for RISC-V.
It implements:
1. Regular implication (A → B)
a. "the extension A implies the extension B"
b. "the extension A requires the extension B"
c. "the extension A depends on the extension B"
2. Extension group or shorthand (A == B1 & B2...)
a. "the extension A is shorthand for other extensions: B1, B2..."
b. "the extension A comprises instructions provided by B1, B2..."
This is implemented as (A → B1 & B2... + B1 & B2... → A)
where the former is a regular implication as required by specifications
and the latter is a "reverse" implication to improve usability.
and prepares for:
3. Implication with multiple requirements (A1 & A2... → B)
a. "A1 + A2 implies B"
b. (implicitly used to implement reverse implication of case 2)
Although it uses macros and iterators, good optimizers turn the series of
implications into fast bit-manipulation operations.
In the case 2 (extension group or shorthand; where a superset extension
is just a collection of other subextensions and provides no features by
a superset itself), specifications do specify that an extension group
implies its members but not vice versa. However, implying an extension
group from its members would improve usability on the feature detection
(especially when the feature provider does not provide existence of such
extension group but provides existence of its members).
Similar "reverse implication" on RISC-V is implemented on LLVM.
Case 3 is implicitly used to implement reverse implication of case 2 but
there's another use case: implication with multiple requirements like
"Zcf" and "Zcd" extensions (not yet implemented in this crate for now).
To handle extension groups perfectly, we need to loop implication several
times (until they converge; normally 2 times and up to 4 times when we add
most of `riscv_hwprobe`-based features).
To make implementation of that loop possible, `cache::Initializer` is
modified to implement `PartialEq` and `Eq`.
This is ported from Taiki Endo's branch and sorted by the `@FEATURE` order
as in `src/detect/arch/riscv.rs`.
Co-Authored-By: Taiki Endo <te316e89@gmail.com>
The "B" extension is once abandoned (instead, it is ratified as a collection
of "Zb*" extensions). However, it is later redefined and ratified as a
superset of "Zba", "Zbb" and "Zbs" extensions (but not "Zbc" carry-less
multiplication for limited benefits and implementation cost).
Although non-functional (because feature detection is not yet implemented),
it provides the foundation to implement this extension (along with
straightforward documentation showing subsets of "B").
The "A" extension comprises instructions provided by the "Zaamo" and
"Zalrsc" extensions. To prepare for the "Zacas" extension (which provides
compare-and-swap instructions and discoverable from Linux) which depends on
the "Zaamo" extension, it would be better to support those subsets.
This commit prepares common infrastructure for extension implication by
removing `enable_features` closure which makes each feature test longer
(because it needs extra `value` argument each time we test a feature).
It comes with the overhead to enable each feature separately but later
mitigated by the OS-independent extension implication logic.
Because this function will be no longer auxvec-only, this commit adds a
comment to mark auxvec-based part.
It *does not* add a comment to "base ISA" part because it may also use
`riscv_hwprobe`-based results.
1. Use canonical kernel.org repository instead of the GitHub mirror.
2. Refer to the fixed commit to guarantee access.
3. Use `uapi` part to ensure that the feature detection is primarily
intended for user-mode programs.
To avoid crashing Clippy, the `bug!()` is used only when debug
assertions are enabled. In regular usage, the result will be the same as
before, but without the extra line printed on the standard output which
has the potential for disrupting shell scripts.
changelog: none
It's a much better name, more consistent with how we name such things.
Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this
field used to have the type `LifetimeRes` and then the type was changed
but the field name remained the same.
It's a much better name, more consistent with how we name such things.
Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this
field used to have the type `LifetimeRes` and then the type was changed
but the field name remained the same.
Apparently there are tests that print canonical paths *and* tests which
print non-canonical paths.
An example of the latter is `tests/ui/type_length_limit.rs`.
Add warning comment to `Take::get_ref` and `Chain::get_ref`
The methods `Take::get_mut` and `Chain::get_mut` include comments
warning about modifying the I/O state of the underlying reader. However,
many readers (e.g. `File`) allow I/O using a shared reference (e.g.
`&File`). So, add the same caveat to the `get_ref` methods.
Remove safe remove
`safe_remove_dir_all` and `safe_remove_file` use `canonicalize` to workaround a `MAX_PATH` limitation. However, this has not been needed in a long time, since the standard library handles this situation itself.
I've kept `safe_remove_file` (without `canonicalize`) because it also returns `Ok` if the file is not found. While, `safe_remove_file` is only used twice, matching on the error kind is sufficiently verbose that maybe it's still worth it?
Normalize ADT field in `find_tails_for_unsizing`
See the comment inline and in the test.
TL;DR is that we're getting getting a type from a `type_of` query and then matching on it structurally in codegen, so we're obligated to normalize it. The fact that this wasn't triggered earlier is that all of the types that have `CoerceUnsized` implementations never encounter aliases when peeling the ADT down to their base reference/ptr type.
**NOTE**: I also renamed some things and reorganized the function a bit.
Fixes#139812Fixes#74451, which I didn't think was interesting enough to add another test.
r? oli-obk
`librustdoc`: more `impl fmt::Display`
Continuation of #137425 and #136828 and #136784
Working towards getting rid of the `write_str` helper
r? `@GuillaumeGomez` (if you want!)
