Jubilee
4f477427b8
Rollup merge of #135731 - frank-king:feature/pin-borrow, r=eholk,traviscross
...
Implement parsing of pinned borrows
This PR implements part of #130494 .
EDIT: It introduces `&pin mut $place` and `&pin const $place` as sugars for `std::pin::pin!($place)` and its shared reference equivalent, except that `$place` will not be moved when borrowing. The borrow check will be in charge of enforcing places cannot be moved or mutably borrowed since being pinned till dropped.
### Implementation steps:
- [x] parse the `&pin mut $place` and `&pin const $place` syntaxes
- [ ] borrowck of `&pin mut|const`
- [ ] support autoref of `&pin mut|const` when needed
2025-06-24 19:45:29 -07:00
Guillaume Gomez
194e58c75c
Rollup merge of #142798 - camsteffen:recover-semi, r=compiler-errors
...
Don't fail to parse a struct if a semicolon is used to separate fields
The first commit is a small refactor.
2025-06-22 17:35:35 +02:00
Cameron Steffen
26a6b55717
Recover from semicolon field separator
2025-06-20 15:30:09 -05:00
Cameron Steffen
6809ec1648
Factor out seen_comma variable
2025-06-20 12:45:26 -05:00
Cameron Steffen
07b9bb1855
Extract Translator struct
2025-06-19 13:02:04 -05:00
Jacob Pratt
e95fb09dfb
Rollup merge of #142371 - fee1-dead-contrib:push-xqlkumzurkus, r=petrochenkov
...
avoid `&mut P<T>` in `visit_expr` etc methods
trying a different way than rust-lang/rust#141636
r? ghost
2025-06-17 23:19:34 +02:00
Jakub Beránek
d68432a1a9
Rollup merge of #142341 - xizheyin:142311, r=fee1-dead
...
Don't suggest converting `///` to `//` when expecting `,`
Fixes rust-lang/rust#142311
2025-06-16 19:54:33 +02:00
xizheyin
c63665cd73
Dont suggest converting /// to regular comment when it appears after missing , in list
...
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn >
2025-06-16 23:07:11 +08:00
Deadbeef
96fd9fc2dd
use if let guards where possible
2025-06-15 15:46:20 +08:00
Frank King
e627f88f88
Implement pinned borrows, part of pin_ergonomics
2025-06-15 10:21:29 +08:00
Jonathan Brouwer
b131b6f630
Rework how the disallowed qualifier lints are generated
...
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com >
2025-06-13 18:13:34 +02:00
Deadbeef
5f0dd44b3b
avoid &mut P<T> in visit_expr etc methods
2025-06-12 17:36:03 +08:00
Lukas Wirth
edc405d383
Add expectation for { when parsing lone coroutine qualifiers
2025-06-11 17:11:58 +02:00
Guillaume Gomez
93ca0af08c
Rollup merge of #141603 - nnethercote:reduce-P, r=fee1-dead
...
Reduce `ast::ptr::P` to a typedef of `Box`
As per the MCP at https://github.com/rust-lang/compiler-team/issues/878 .
r? `@fee1-dead`
2025-06-06 23:53:16 +02:00
Josh Stone
af2a85bd75
Ensure stack in Parser::parse_ty
...
This solve a stack overflow found on Fedora s390x when building
`tests/ui/associated-consts/issue-93775.rs`.
2025-06-04 15:21:30 -07:00
Matthias Krüger
0736a03a78
Rollup merge of #141570 - chenyukang:yukang-fix-eq_unspanned, r=workingjubilee
...
Fix incorrect eq_unspanned in TokenStream
Fixes rust-lang/rust#141522
r? ``@workingjubilee``
should we remove this function?
since it's used in several places, i'd prefer to keep it.
2025-06-04 16:24:07 +02:00
Matthias Krüger
96531418f8
Rollup merge of #141945 - nnethercote:rm-Path-is_ident, r=compiler-errors
...
Remove `Path::is_ident`.
It checks that a path has a single segment that matches the given symbol, and that there are zero generic arguments. It has a single use.
We also have `impl PartialEq<Symbol> for Path` which does exactly the same thing *except* it doesn't check for zero generic arguments, which seems like an oversight. It has numerous uses.
This commit removes `Path::is_ident`, adds a test for zero generic arguments to `PartialEq<Symbol> for Path`, and changes the single use of `is_ident` to instead use `==`.
r? `@wesleywiser`
2025-06-03 21:53:38 +02:00
Oli Scherer
5fbdfc3e10
Add iter macro
...
This adds an `iter!` macro that can be used to create movable
generators.
This also adds a yield_expr feature so the `yield` keyword can be used
within iter! macro bodies. This was needed because several unstable
features each need `yield` expressions, so this allows us to stabilize
them separately from any individual feature.
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de >
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com >
Co-authored-by: Travis Cross <tc@traviscross.com >
2025-06-03 10:52:32 -07:00
Nicholas Nethercote
04391045d0
Remove Path::is_ident.
...
It checks that a path has a single segment that matches the given
symbol, and that there are zero generic arguments. It has a single use.
We also have `impl PartialEq<Symbol> for Path` which does exactly the
same thing *except* it doesn't check for zero generic arguments, which
seems like an oversight. It has numerous uses.
This commit removes `Path::is_ident`, adds a test for zero generic
arguments to `PartialEq<Symbol> for Path`, and changes the single use of
`is_ident` to instead use `==`.
2025-06-03 15:21:33 +10:00
Jubilee
5e139db47b
Rollup merge of #141077 - chenyukang:yukang-fix-140991-comma, r=wesleywiser
...
Fix the issue of typo of comma in arm parsing
Fixes #140991
I also checked is it a '/', since it's near from ',' from keyboard.
2025-05-30 13:52:25 -07:00
Jacob Pratt
0ac0285c3f
Rollup merge of #141675 - nnethercote:ItemKind-field-order, r=fee1-dead
...
Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
r? `@fee1-dead`
2025-05-29 04:49:43 +02:00
Trevor Gross
d6b1108cda
Rollup merge of #141670 - chenyukang:yukang-fix-ice-from-contracts, r=nnethercote
...
Fix ICE in tokenstream with contracts from parser recovery
Fixes rust-lang/rust#140683
After two times of parsing error, the `recover_stmt_` constructs an error ast, then when we expand macors, the invalid tokenstream triggered ICE because of mismatched delims.
Expected `{` and get other tokens is an obvious error message, too much effort on recovery may introduce noise.
r? ```@nnethercote```
2025-05-28 10:28:11 -04:00
Nicholas Nethercote
4c4a40f6df
Reorder ast::ItemKind::{Struct,Enum,Union} fields.
...
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
2025-05-28 15:48:45 +10:00
yukang
adcd0bf5c3
Fix ICE in tokenstream with contracts from parser recovery
2025-05-28 09:35:10 +08:00
Folkert de Vries
c7c0194d98
move asm parsing code into rustc_parse
2025-05-27 09:44:10 +02:00
Nicholas Nethercote
991c91fdaa
Reduce P<T> to a typedef of Box<T>.
...
Keep the `P` constructor function for now, to minimize immediate churn.
All the `into_inner` calls are removed, which is nice.
2025-05-27 13:29:24 +10:00
Nicholas Nethercote
0f285e346f
Remove the one use of P<[T]>.
...
A `Vec` is fine, the additional word (vector vs. boxed slice) doesn't
matter here.
2025-05-27 02:54:18 +10:00
yukang
d3347bb32b
remove eq_unspanned from TokenStream
2025-05-26 17:02:51 +08:00
yukang
5f8954bc41
Fix the issue of typo of comma in arm parsing
2025-05-16 12:40:04 +02:00
Jamie
1267333ef1
Improve ternary operator recovery
2025-05-14 13:32:59 +01:00
Nicholas Nethercote
0984db553d
Remove Ident::empty.
...
All uses have been removed. And it's nonsensical: an identifier by
definition has at least one char.
The commits adds an is-non-empty assertion to `Ident::new` to enforce
this, and converts some `Ident` constructions to use `Ident::new`.
Adding the assertion requires making `Ident::new` and
`Ident::with_dummy_span` non-const, which is no great loss.
The commit amends a couple of places that do path splitting to ensure no
empty identifiers are created.
2025-05-09 13:57:49 +10:00
xizheyin
b922da3586
Use parse_param_general when parsing (T, U)->R in parse_path_segment
...
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn >
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com >
2025-05-07 22:56:14 +08:00
Matthias Krüger
a477172ced
Rollup merge of #140494 - ehuss:document-restrictions, r=traviscross,SparrowLii
...
Parser: Document restrictions
I had trouble easily understanding what these various flags do. This is my attempt to try to explain what these do.
2025-04-30 22:36:44 +02:00
Vadim Petrochenkov
6668d13de2
ast: Remove token visiting from AST visitor
...
It's no longer necessary after the removal of nonterminal tokens in #124141 .
2025-04-30 10:36:03 +03:00
Eric Huss
2b92f9fb98
Parser: Document restrictions
...
I had trouble easily understanding what these various flags do. This is
my attempt to try to explain what these do.
2025-04-29 18:05:45 -07:00
Nicholas Nethercote
880e6f716d
Use ThinVec to shrink LazyAttrTokenStreamInner.
2025-04-30 07:12:09 +10:00
Nicholas Nethercote
298c56f4ba
Simplify LazyAttrTokenStream.
...
This commit does the following.
- Changes it from `Lrc<Box<dyn ToAttrTokenStream>>` to
`Lrc<LazyAttrTokenStreamInner>`.
- Reworks `LazyAttrTokenStreamImpl` as `LazyAttrTokenStreamInner`, which
is a two-variant enum.
- Removes the `ToAttrTokenStream` trait and the two impls of it.
The recursion limit must be increased in some crates otherwise rustdoc
aborts.
2025-04-30 07:10:56 +10:00
Nicholas Nethercote
28236ab703
Move various token stream things from rustc_parse to rustc_ast.
...
Specifically: `TokenCursor`, `TokenTreeCursor`,
`LazyAttrTokenStreamImpl`, `FlatToken`, `make_attr_token_stream`,
`ParserRange`, `NodeRange`. `ParserReplacement`, and `NodeReplacement`.
These are all related to token streams, rather than actual parsing.
This will facilitate the simplifications in the next commit.
2025-04-29 12:14:27 +10:00
Kivooeo
f072d30741
resolved conflict
2025-04-25 17:02:59 +05:00
Matthias Krüger
f45d2bd8ee
Rollup merge of #140228 - fmease:revert-overzealous-colon-recovery, r=jieyouxu
...
Revert overzealous parse recovery for single colons in paths
Basically manually reverts #136808 , cc ``@chenyukang`` ``@estebank.``
Reopens #129273 .
Fixes [after beta backport] #140227 .
2025-04-24 11:40:47 +02:00
León Orell Valerian Liehr
16da97be2f
Revert overzealous parse recovery for single colons
2025-04-24 02:57:10 +02:00
bors
553600e0f5
Auto merge of #140180 - ChrisDenton:rollup-5pvs08u, r=ChrisDenton
...
Rollup of 7 pull requests
Successful merges:
- #140142 (Some more graphviz tweaks)
- #140146 (Update `compiler_builtins` to 0.1.156)
- #140147 (Clean: rename `open_braces` to `open_delimiters` in lexer and move `make_unclosed_delims_error` into `diagnostics.rs`.)
- #140160 (Use `is_lang_item` and `as_lang_item` instead of handrolling their logic)
- #140163 (Validate extension in `PathBuf::add_extension`)
- #140173 (Ping Mara when touching format_args!() internals.)
- #140175 (`rc""` more clear error message)
r? `@ghost`
`@rustbot` modify labels: rollup
2025-04-23 15:12:33 +00:00
Chris Denton
090f6a9629
Rollup merge of #140147 - xizheyin:issue-138401-1, r=compiler-errors
...
Clean: rename `open_braces` to `open_delimiters` in lexer and move `make_unclosed_delims_error` into `diagnostics.rs`.
Clean code prepared for resolving #138401 . To avoid having too many extraneous changes in one PR, I cleaned up some of the naming and method placement in lexer in this PR.
1. For the make_unclosed_delims_error function defined in mod.rs is only used in lexer, so moved into lexer, which enhances encapsulation.
2. For open_braces in TokenTreeDiagInfo the naming is not canonical, as Brace refers to `{...} ` and this variable can store all kinds of different Delimiters. so I named it open_delimiters.
r? `@chenyukang`
2025-04-23 00:43:06 +00:00
Chris Denton
15f8847a25
Rollup merge of #140144 - nnethercote:fix-140098, r=petrochenkov
...
Handle another negated literal in `eat_token_lit`.
Extends the change from #139653 , which was on expressions, to literals.
Fixes #140098 .
r? ``@petrochenkov``
2025-04-22 15:24:08 +00: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.rs4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs#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.rs4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs4adafcf40a/tests/ui/drop/issue-100276.rs4adafcf40a/tests/ui/drop/drop_order.rs4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs4adafcf40a/tests/ui/drop/drop_order_if_let_rescope.rs4adafcf40a/tests/ui/mir/mir_let_chains_drop_order.rs4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs4adafcf40a/tests/ui/mir/issue-99852.rs#102394
### Linting
[`irrefutable-lets.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs4adafcf40a/tests/ui/lint/issue-121070-let-range.rs2128d8df0e/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs4adafcf40a/tests/ui/parser/issues/issue-103381.rs4adafcf40a/tests/ui/parser/semi-in-let-chain.rs4adafcf40a/tests/ui/parser/deli-ident-issue-1.rs4adafcf40a/tests/ui/parser/brace-in-let-chain.rs4adafcf40a/tests/ui/pattern/usefulness/conflicting_bindings.rs4adafcf40a/tests/ui/expr/if/attrs/let-chains-attr.rs4adafcf40a/tests/coverage/branch/if-let.rs4adafcf40a/tests/mir-opt/building/logical_or_in_conditional.rs4adafcf40a/tests/ui/macros/stringify.rs4adafcf40a/tests/ui/unpretty/expanded-interpolation.rs4adafcf40a/tests/ui/unpretty/expanded-exhaustive.rs4adafcf40a/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rshttps://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
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
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
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
bf8ce32558
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 {
```
2025-04-21 07:35:56 +10:00
est31
5258cb76a5
Don't call ungate_last
2025-04-20 23:14:55 +02:00
