bors
6bc57c6bf7
Auto merge of #139960 - amandasystems:placeholder-ui-tests, r=lcnr
...
Add tests for two untested cases of placeholder relations
During work on #130227 , I discovered several situations not covered by any previously existing UI test. This commit introudces tests to cover that.
r? lcnr
2025-04-22 11:05:54 +00:00
Oli Scherer
5d2952100f
Use is_lang_item and as_lang_item instead of handrolling their logic
2025-04-22 11:02:37 +00:00
Lukas Wirth
7735f18620
Merge pull request #19624 from jackh726/chalk-update
...
Update chalk
2025-04-22 10:58:31 +00:00
Amanda Stjerna
e9d374c657
Add tests for two untested cases of placeholder relations
...
During work on #130227 , I discovered several situations not covered by any
previously existing UI test. This commit introudces tests to cover that.
2025-04-22 12:07:53 +02:00
Ralf Jung
5d6c6e01c6
Merge pull request #4285 from RalfJung/tb-tests
...
TB: add missing interior_mutability test file
2025-04-22 09:44:48 +00:00
Ralf Jung
47a1278841
add comment for "Other" case
2025-04-22 11:40:48 +02:00
Ralf Jung
ae3adaec6d
TB: add missing interior_mutability test file
2025-04-22 11:19:57 +02:00
Trevor Gross
5028ecd025
chore: Release libm v0.2.13
2025-04-22 04:44:00 -04:00
Trevor Gross
d30dde73b3
fix: Switch to resolver v2
...
The published crates fail to build with an edition less than 2024
because they are packaged with `resolver = "3"`, which is a 2024-only
option. Revert back to resolver v2 to drop this requirement.
Fixes: https://github.com/rust-lang/compiler-builtins/issues/883
2025-04-22 04:00:49 -04:00
bors
8bf5a8d12f
Auto merge of #132833 - est31:stabilize_let_chains, r=fee1-dead
...
Stabilize let chains in the 2024 edition
# Stabilization report
This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust.
[tracking issue]: https://github.com/rust-lang/rust/issues/53667
[RFC 2497]: https://github.com/rust-lang/rfcs/pull/2497
[2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html
## What is being stabilized
The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable.
```Rust
struct FnCall<'a> {
fn_name: &'a str,
args: Vec<i32>,
}
fn is_legal_ident(s: &str) -> bool {
s.chars()
.all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c))
}
impl<'a> FnCall<'a> {
fn parse(s: &'a str) -> Option<Self> {
if let Some((fn_name, after_name)) = s.split_once("(")
&& !fn_name.is_empty()
&& is_legal_ident(fn_name)
&& let Some((args_str, "")) = after_name.rsplit_once(")")
{
let args = args_str
.split(',')
.map(|arg| arg.parse())
.collect::<Result<Vec<_>, _>>();
args.ok().map(|args| FnCall { fn_name, args })
} else {
None
}
}
fn exec(&self) -> Option<i32> {
let iter = self.args.iter().copied();
match self.fn_name {
"sum" => Some(iter.sum()),
"max" => iter.max(),
"min" => iter.min(),
_ => None,
}
}
}
fn main() {
println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec());
println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec());
}
```
The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition.
closes #53667
## Why 2024 edition?
Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords.
In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`].
In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function.
[generate correct MIR]: https://github.com/rust-lang/rust/issues/104843
[stay consistent with `if let`]: https://github.com/rust-lang/rust/pull/103293#issuecomment-1293408574
[drop order changes]: https://github.com/rust-lang/rust/issues/124085
## Introduction considerations
As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below.
## Implementation history
* History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted.
* https://github.com/rust-lang/rust/pull/94927
* https://github.com/rust-lang/rust/pull/94951
* https://github.com/rust-lang/rust/pull/94974
* https://github.com/rust-lang/rust/pull/95008
* https://github.com/rust-lang/rust/pull/97295
* https://github.com/rust-lang/rust/pull/98633
* https://github.com/rust-lang/rust/pull/99731
* https://github.com/rust-lang/rust/pull/102394
* https://github.com/rust-lang/rust/pull/100526
* https://github.com/rust-lang/rust/pull/100538
* https://github.com/rust-lang/rust/pull/102998
* https://github.com/rust-lang/rust/pull/103405
* https://github.com/rust-lang/rust/pull/103293
* https://github.com/rust-lang/rust/pull/107251
* https://github.com/rust-lang/rust/pull/110568
* https://github.com/rust-lang/rust/pull/115677
* https://github.com/rust-lang/rust/pull/117743
* https://github.com/rust-lang/rust/pull/117770
* https://github.com/rust-lang/rust/pull/118191
* https://github.com/rust-lang/rust/pull/119554
* https://github.com/rust-lang/rust/pull/129394
* https://github.com/rust-lang/rust/pull/132828
* https://github.com/rust-lang/reference/pull/1179
* https://github.com/rust-lang/reference/pull/1251
* https://github.com/rust-lang/rustfmt/pull/5910
[original stabilization PR]: https://github.com/rust-lang/rust/pull/94927
## Adoption history
### In the compiler
* History before March 14, 2022 can be found in the [original stabilization PR].
* https://github.com/rust-lang/rust/pull/115983
* https://github.com/rust-lang/rust/pull/116549
* https://github.com/rust-lang/rust/pull/116688
### Outside of the compiler
* https://github.com/rust-lang/rust-clippy/pull/11750
* [rspack](https://github.com/web-infra-dev/rspack )
* [risingwave](https://github.com/risingwavelabs/risingwave )
* [dylint](https://github.com/trailofbits/dylint )
* [convex-backend](https://github.com/get-convex/convex-backend )
* [tikv](https://github.com/tikv/tikv )
* [Daft](https://github.com/Eventual-Inc/Daft )
* [greptimedb](https://github.com/GreptimeTeam/greptimedb )
## Tests
<details>
### Intentional restrictions
[`partially-macro-expanded.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs ), [`macro-expanded.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs ): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand.
[`parens.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs ): `if (let pat = expr)` is not allowed in chains
[`ensure-that-let-else-does-not-interact-with-let-chains.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs ): `let...else` doesn't support chaining.
### Overlap with match guards
[`move-guard-if-let-chain.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs ): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let`
[`shadowing.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs ): shadowing in if let guards works as expected
[`ast-validate-guards.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs ): let chains in match guards require the match guards feature gate
### Simple cases from the early days
PR #88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs.
[`then-else-blocks.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs )
[`ast-lowering-does-not-wrap-let-chains.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs )
[`issue-90722.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs )
[`issue-92145.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs )
### Drop order/MIR scoping tests
[`issue-100276.rs`](4adafcf40a/tests/ui/drop/issue-100276.rs ): let expressions on RHS aren't terminating scopes
[`drop_order.rs`](4adafcf40a/tests/ui/drop/drop_order.rs ): exhaustive temporary drop order test for various Rust constructs, including let chains
[`scope.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs ): match guard scoping test
[`drop-scope.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs ): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm
[`drop_order_if_let_rescope.rs`](4adafcf40a/tests/ui/drop/drop_order_if_let_rescope.rs ): if let rescoping on edition 2024, including chains
[`mir_let_chains_drop_order.rs`](4adafcf40a/tests/ui/mir/mir_let_chains_drop_order.rs ): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024.
[`issue-99938.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs ), [`issue-99852.rs`](4adafcf40a/tests/ui/mir/issue-99852.rs ) both bad MIR ICEs fixed by #102394
### Linting
[`irrefutable-lets.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs ): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`.
[`issue-121070-let-range.rs`](4adafcf40a/tests/ui/lint/issue-121070-let-range.rs ): regression test for false positive of the unused parens lint, precedence requires the `()`s here
### Parser: intentional restrictions
[`disallowed-positions.rs`](2128d8df0e/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs ): `let` in expression context is rejected everywhere except at the top level
[`invalid-let-in-a-valid-let-context.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs ): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`).
### Parser: recovery
[`issue-103381.rs`](4adafcf40a/tests/ui/parser/issues/issue-103381.rs ): Graceful recovery of incorrect chaining of `if` and `if let`
[`semi-in-let-chain.rs`](4adafcf40a/tests/ui/parser/semi-in-let-chain.rs ): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s)
[`deli-ident-issue-1.rs`](4adafcf40a/tests/ui/parser/deli-ident-issue-1.rs ), [`brace-in-let-chain.rs`](4adafcf40a/tests/ui/parser/brace-in-let-chain.rs ): Ensure that stray unclosed `{`s in let chains give nice errors and hints
### Misc
[`conflicting_bindings.rs`](4adafcf40a/tests/ui/pattern/usefulness/conflicting_bindings.rs ): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well.
[`let-chains-attr.rs`](4adafcf40a/tests/ui/expr/if/attrs/let-chains-attr.rs ): attributes work on let chains
### Tangential tests with `#![feature(let_chains)]`
[`if-let.rs`](4adafcf40a/tests/coverage/branch/if-let.rs ): MC/DC coverage tests for let chains
[`logical_or_in_conditional.rs`](4adafcf40a/tests/mir-opt/building/logical_or_in_conditional.rs ): not really about let chains, more about dropping/scoping behaviour of `||`
[`stringify.rs`](4adafcf40a/tests/ui/macros/stringify.rs ): exhaustive test of the `stringify` macro
[`expanded-interpolation.rs`](4adafcf40a/tests/ui/unpretty/expanded-interpolation.rs ), [`expanded-exhaustive.rs`](4adafcf40a/tests/ui/unpretty/expanded-exhaustive.rs ): Exhaustive test of `-Zunpretty`
[`diverges-not.rs`](4adafcf40a/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs ): Never type, mostly tangential to let chains
</details>
## Possible future work
* There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax.
* https://github.com/rust-lang/lang-team/issues/297
* One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly.
* Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work).
[RFC 3573]: https://github.com/rust-lang/rfcs/pull/3573
[`if_let_guard` tracking issue]: https://github.com/rust-lang/rust/issues/51114
## Open questions / blockers
- [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [#117977 ](https://github.com/rust-lang/rust/issues/117977 )
- [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [#103476 ](https://github.com/rust-lang/rust/issues/103476 ). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in #133093
- [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093
- [x] Parsing rejection tests: addressed by https://github.com/rust-lang/rust/pull/132828
- [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting ): https://github.com/rust-lang/rust/pull/139456
- [x] https://github.com/rust-lang/rust/issues/86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`.
- [x] Documentation in the reference: https://github.com/rust-lang/reference/pull/1740
- [x] Add chapter to the Rust 2024 [edition guide]: https://github.com/rust-lang/edition-guide/pull/337
- [x] Resolve open questions on desired drop order.
[original reference PR]: https://github.com/rust-lang/reference/pull/1179
[edition guide]: https://github.com/rust-lang/edition-guide
2025-04-22 07:54:10 +00:00
Ralf Jung
5717623778
MANTISSA_DIGITS: explain relation to bitwise representation
2025-04-22 09:07:05 +02:00
Ralf Jung
e7a865448a
test_nan: ensure the NAN contant is quiet
2025-04-22 09:06:43 +02:00
xizheyin
dce5d99ce8
Rename open_brace to open_delimiters
...
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-04-22 14:37:26 +08:00
xizheyin
e827b17ddb
Move make_unclosed_delims_error to lexer/diagonostics.rs
...
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-04-22 14:37:26 +08:00
Trevor Gross
e800bf7df4
Update compiler_builtins to 0.1.156
...
Includes the following changes:
* Provide `abort` on AVR [1]
[1]: https://github.com/rust-lang/compiler-builtins/pull/830
2025-04-22 05:46:51 +00:00
Thalia Archibald
01485c9fe9
Unify owned Env types between platforms
...
Also, update the same pattern of reuse in `sys::args` to match.
2025-04-21 22:38:22 -07:00
Trevor Gross
aec649faae
chore: Combine CHANGELOG files for compiler-builtins
...
This unintentionally got split when compiler-builtins was moved to a
subdirectory.
2025-04-22 01:34:46 -04:00
github-actions[bot]
1fa9d0fce3
chore: release builtins 0.1.156 and libm 0.2.12
2025-04-22 01:34:46 -04:00
Oli Scherer
f456b40240
Merge pull request #4284 from rust-lang/rustup-2025-04-22
...
Automatic Rustup
2025-04-22 05:26:48 +00:00
Manuel Drehwald
deed996704
Merge pull request #2350 from rust-lang/update-autodiff-build-instr
...
update build and test instructions
2025-04-22 01:17:18 -04:00
Manuel Drehwald
e9896ccc1e
update build and test instructions
2025-04-22 01:16:04 -04:00
Nicholas Nethercote
6be270be0c
Handle another negated literal in eat_token_lit.
...
Extends the change from #139653 , which was on expressions, to literals.
Fixes #140098 .
2025-04-22 15:08:32 +10:00
The Miri Cronjob Bot
daa250f912
Merge from rustc
2025-04-22 05:00:59 +00:00
Thalia Archibald
4695212566
Deduplicate unsupported env items
2025-04-21 21:58:58 -07:00
The Miri Cronjob Bot
9d16f6666d
Preparing for merge from rustc
2025-04-22 04:53:59 +00:00
quaternic
e075e9fbde
Reimplement the generic fmod
2025-04-22 00:53:56 -04:00
bors
9bfa31f632
Auto merge of #140138 - ChrisDenton:rollup-zw7jibi, r=ChrisDenton
...
Rollup of 5 pull requests
Successful merges:
- #139981 (Don't compute name of associated item if it's an RPITIT)
- #140077 (Construct OutputType using macro and print [=FILENAME] help info)
- #140081 (Update `libc` to 0.2.172)
- #140094 (Improve diagnostics for pointer arithmetic += and -= (fixes #137391 ))
- #140128 (Use correct annotation for CSS pseudo elements)
r? `@ghost`
`@rustbot` modify labels: rollup
2025-04-22 04:44:13 +00:00
Thalia Archibald
1b00ebefdf
Update !DynSend and !DynSync platform impls
...
These have grown out of sync with the platforms.
2025-04-21 21:23:32 -07:00
bit-aloo
b8ca0073c8
move autodiff pretty test to a autodiff sub module
2025-04-22 09:53:08 +05:30
Thalia Archibald
6518bcb967
Fix unsafe_op_in_unsafe_fn for Unix env
2025-04-21 21:17:16 -07:00
Thalia Archibald
dfc8f02279
Move zkVM constants into sys::env_consts
...
I missed this in #139868 . Its `mod` declaration was removed, but the
contents were not moved.
2025-04-21 21:05:04 -07:00
Thalia Archibald
90fe2805df
Move sys::pal::os::Env into sys::env
...
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are
publicly exposed via `std::env`, their implementations are each
self-contained. Keep them separate in `std::sys` and make a new module,
`sys::env`, for `Env`.
2025-04-21 20:56:43 -07:00
bit-aloo
a7c7119ed2
Added test
2025-04-22 09:08:33 +05:30
Trevor Gross
a8652953e4
Rename the public-test-deps feature to unstable-public-internals
...
`compiler-builtins` uses `public-test-deps`, `libm` uses
`unstable-public-internals`. Consolidate these under the `libm` name.
Once compiler-builtins is no longer published, this feature can probably
be dropped.
Also switch to `dep:` syntax for features that enable dependencies.
2025-04-21 23:24:52 -04:00
Trevor Gross
13b94cf89f
ci: Fix extensive tests
...
Move this to a script and ensure only `libm-test` gets built to avoid
default feature issues with `compiler-builtins`.
2025-04-21 22:50:42 -04:00
Jason Newcomb
aeb6ac9a0b
Fix question_mark suggesting when type is behind Deref include parentheses ( #14655 )
...
Close rust-lang/rust-clippy#14615
changelog: [`question_mark`]: when type is behind Deref include
parentheses
2025-04-22 01:58:56 +00:00
Chris Denton
ddf01760ac
Rollup merge of #140128 - GuillaumeGomez:pseudo-elements, r=notriddle
...
Use correct annotation for CSS pseudo elements
The list of CSS pseudo elements is pretty short so it was easy to go through. Even though the `:` is accepted, it's incorrect.
For a description of CSS pseudo elements: https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements
r? ``@notriddle``
2025-04-22 01:22:14 +00:00
Chris Denton
8f42ac0043
Rollup merge of #140094 - Kivooeo:raw-pointer-assignment-suggestion, r=compiler-errors
...
Improve diagnostics for pointer arithmetic += and -= (fixes #137391 )
**Description**:
This PR improves the diagnostic message for cases where a binary assignment operation like `ptr += offset` or `ptr -= offset` is attempted on `*mut T`. These operations are not allowed, and the compiler previously suggested calling `.add()` or `.wrapping_add()`, which is misleading if not assigned.
This PR updates the diagnostics to suggest assigning the result of `.wrapping_add()` or `.wrapping_sub()` back to the pointer, e.g.:
**Examples**
For this code
```rust
let mut arr = [0u8; 10];
let mut ptr = arr.as_mut_ptr();
ptr += 2;
```
it will say:
```rust
10 | ptr += 2;
| ---^^^^^
| |
| cannot use `+=` on type `*mut u8`
|
help: consider replacing `ptr += offset` with `ptr = ptr.wrapping_add(offset)` or `ptr.add(offset)`
|
10 - ptr += 2;
10 + ptr = ptr.wrapping_add(2);
```
**Related issue**: #137391
cc `@nabijaczleweli` for context (issue author)
2025-04-22 01:22:13 +00:00
Chris Denton
07a28ec2fb
Rollup merge of #140081 - Berrysoft:update-libc-172, r=tgross35
...
Update `libc` to 0.2.172
r? ````@joboet````
2025-04-22 01:22:13 +00:00
Chris Denton
2fff8257ad
Rollup merge of #140077 - xizheyin:issue-139805, r=jieyouxu
...
Construct OutputType using macro and print [=FILENAME] help info
Closes #139805
Use define_output_types to define variants of OutputType, as well as refactor all of its methods for clarity. This way no variant is missed when pattern matching or output help messages.
On top of that, I optimized for `emit` help messages.
r? ```@jieyouxu```
2025-04-22 01:22:12 +00:00
Chris Denton
32862fba47
Rollup merge of #139981 - compiler-errors:name-2, r=nnethercote
...
Don't compute name of associated item if it's an RPITIT
Another simple fix for an RPITIT name ICE.
Fixes https://github.com/rust-lang/rust/issues/139941
Fixes #140084
r? nnethercote
2025-04-22 01:22:11 +00:00
Tsukasa OI
2ef4f78af1
rustc_target: Adjust RISC-V feature implication
...
This commit adjusts feature implication of the RISC-V ISA for better
feature detection from the user perspective.
The main rule is:
If the feature A is a functional superset of the feature B (A ⊃ B),
A is to imply B, even if this implication is not on the manual.
Such implications (not directly referred in the ISA manual) are commented
as "A ⊃ B" which means "A is a (functional) superset of B".
1. Zbc → Zbkc (add as a superset)
The Zbkc extension is a subset of the Zbc extension
(Zbc - "clmulr" instruction == Zbkc)
2. Zkr → (nothing) (remove dependency to Zicsr)
Implication to the Zicsr extension is removed because (although nearly
harmless), the Zkr extension (or the "seed" CSR section) defines its own
subset of the Zicsr extension.
3. Zvbb → Zvkb (comment as a superset)
This implication was already there but not denoted as a functional
superset. This commit adds the comment.
4. Zvfh → Zvfhmin (comment as a superset)
This is similar to the case above (Zvbb → Zvkb).
5. Zvfh → Zve32f (add implication per the ISA specification)
This dependency is on the ISA manual but was missing (due to the fact
that Zvfh indirectly implies Zve32f on the current implementation
through Zvfh → Zvfhmin, which is a functional relation).
This commit ensures that this is *also* ISA-compliant in the
source code level (there's no functional changes though).
6. Zvknhb → Zvknha (add as a superset)
The Zvknhb extension (SHA-256 / SHA-512) is a functional superset of
the Zvknha extension (SHA-256 only).
2025-04-22 01:21:19 +00:00
bors
fae7785b60
Auto merge of #139897 - nnethercote:rm-OpenDelim-CloseDelim, r=petrochenkov
...
Remove `token::{Open,Close}Delim`
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`.
PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by
replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless
variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing
with delimiters. It also makes `ast::TokenKind` more similar to
`parser::TokenType`.
This requires a few new methods:
- `TokenKind::is_{,open_,close_}delim()` replace various kinds of
pattern matches.
- `Delimiter::as_{open,close}_token_kind` are used to convert
`Delimiter` values to `TokenKind`.
Despite these additions, it's a net reduction in lines of code. This is
because e.g. `token::OpenParen` is so much shorter than
`token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms
reduce to single line forms. And many places where the number of lines
doesn't change are still easier to read, just because the names are
shorter, e.g.:
```
- } else if self.token != token::CloseDelim(Delimiter::Brace) {
+ } else if self.token != token::CloseBrace {
```
r? `@petrochenkov`
2025-04-22 01:15:06 +00:00
Nicholas Nethercote
521b379705
Remove unnecessary lifetime on ResultsVisitor.
2025-04-22 10:08:05 +10:00
Nicholas Nethercote
3bd1e1484f
Remove unused ResultsCursor methods.
2025-04-22 09:46:24 +10:00
Nicholas Nethercote
55a80cc132
Move StateDiffCollector's use point.
...
Currently the graphviz code does a `results.visit_with` call while also
holding a `ResultsCursor` on the `results`. That is both kinds of
results traversals at the same time, which is awkward. This commit moves
the `results.visit_with` part earlier so the two results traversals
don't overlap.
2025-04-22 09:45:44 +10:00
mejrs
d2d844c65d
Improve rustc_on_unimplemented ui test
2025-04-22 00:19:49 +02:00
Chayim Refael Friedman
5c6f09810c
Resolve offset_of!() in IDE
2025-04-22 00:33:06 +03:00
Folkert de Vries
0103c583fa
support -Zmin-function-alignment ( #1572 )
2025-04-21 22:19:19 +02:00
Kivooeo
b5e8f1f0ce
improve diagnostic for raw pointer field access using ->
2025-04-22 00:53:12 +05:00