| Age | Commit message (Collapse) | Author | Lines |
|
Remove `box_syntax`
r? `@Nilstrieb`
This removes the feature `box_syntax`, which allows the use of `box <expr>` to create a Box, and finalises removing use of the feature from the compiler. `box_patterns` (allowing the use of `box <pat>` in a pattern) is unaffected.
It also removes `ast::ExprKind::Box` - the only way to create a 'box' expression now is with the rustc-internal `#[rustc_box]` attribute.
As a temporary measure to help users move away, `box <expr>` now parses the inner expression, and emits a `MachineApplicable` lint to replace it with `Box::new`
Closes #49733
|
|
|
|
|
|
|
|
r=compiler-errors
Remove unclosed_delims from parser
After landing https://github.com/rust-lang/rust/pull/108297
we could remove `unclosed_delims` from the parser now.
|
|
|
|
|
|
|
|
fix #108495, postfix decrement and prefix decrement has no warning
Fixes #108495
|
|
|
|
|
|
|
|
|
|
|
|
This resolves an inconsistency in naming style for functions
on the parser, between functions parsing specific kinds of items
and those for expressions, favoring the parse_item_[sth] style
used by functions for items. There are multiple advantages
of that style:
* functions of both categories are collected in the same place
in the rustdoc output.
* it helps with autocompletion, as you can narrow down your
search for a function to those about expressions.
* it mirrors rust's path syntax where less specific things
come first, then it gets more specific, i.e.
std::collections::hash_map::Entry
The disadvantage is that it doesn't "read like a sentence"
any more, but I think the advantages weigh more greatly.
This change was mostly application of this command:
sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs
Plus very minor fixes outside of rustc_parse, and an invocation
of x fmt.
|
|
|
|
|
|
|
|
This commit changes the sequence parsers to produce `ThinVec`, which
triggers numerous conversions.
|
|
|
|
|
|
|
|
|
|
Replace `ConstFnMutClosure` with const closures
Also fixes a parser bug. cc `@oli-obk` for compiler changes
|
|
Improve `TokenCursor`.
Some small improvements, for things that were bugging me.
Best reviewed one commit at a time.
r? ``@petrochenkov``
|
|
The motivation here is to eliminate the `Option<(Delimiter,
DelimSpan)>`, which is `None` for the outermost token stream and `Some`
for all other token streams.
We are already treating the innermost frame specially -- this is the
`frame` vs `stack` distinction in `TokenCursor`. We can push that
further so that `frame` only contains the cursor, and `stack` elements
contain the delimiters for their children. When we are in the outermost
token stream `stack` is empty, so there are no stored delimiters, which
is what we want because the outermost token stream *has* no delimiters.
This change also shrinks `TokenCursor`, which shrinks `Parser` and
`LazyAttrTokenStreamImpl`, which is nice.
|
|
|
|
|
|
This is required in order to support translatable diagnostics.
|
|
|
|
|
|
|
|
Make the "extra if in let...else block" hint a suggestion
Changes the hint to a suggestion, suggested in #107213.
r? ```@estebank```
|
|
Fix invalid float literal suggestions when recovering an integer
Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
r? nnethercote
|
|
|
|
Only suggest adding a zero to integers with a preceding dot when the change will
result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
|
|
|
|
Adds an additional hint to failures where we encounter an else keyword
while we're parsing an if-let block.
This is likely that the user has accidentally mixed if-let and let...else
together.
|
|
Recover labels written as identifiers
This adds recovery for `break label expr` and `continue label`, as well as a test for `break label`.
|
|
Allocate one less vec while parsing arrays
Probably does not matter, but imo a little bit nicer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix #82051.
|
|
|
|
|
|
Allow .. to be parsed as let initializer
.. and ..= are valid expressions, however when used in a let statement
it is not parsed.
Fixes #105634
|