| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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 ICE: check if snippet is `)`
Fixes #107705
|
|
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #108376 (compiler/rustc_session: fix sysroot detection logic)
- #108400 (add llvm cgu instructions stats to perf)
- #108496 (fix #108495, postfix decrement and prefix decrement has no warning)
- #108505 (Further unify validity intrinsics)
- #108520 (Small cleanup to `one_bound_for_assoc_type`)
- #108560 (Some `infer/mod.rs` cleanups)
- #108563 (Make mailmap more correct)
- #108564 (Fix `x clean` with specific paths)
- #108571 (Add contains_key to SortedIndexMultiMap)
- #108578 (Update Fuchsia platform team members)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix #108495, postfix decrement and prefix decrement has no warning
Fixes #108495
|
|
Exit when there are unmatched delims to avoid noisy diagnostics
From https://github.com/rust-lang/rust/pull/104012#issuecomment-1311764832
r? ``@petrochenkov``
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replace parse_[sth]_expr with parse_expr_[sth] function names
This resolves an inconsistency in naming style for functions on the parser, where:
* functions parsing specific kinds of items are named `parse_item_[sth]` and
* functions parsing specific kinds of *expressions* are named `parse_[sth]_expr`
favoring the 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](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html).
* 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 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.
|
|
We currently provide wrong suggestions and unhelpful errors on closure
bodies with braces missing. For example, given the following code:
```
fn main() {
let _x = Box::new(|x|x+1;);
}
```
the current output is like this:
```
error: expected expression, found `)`
--> ./main.rs:2:30
|
2 | let _x = Box::new(|x|x+1;);
| ^ expected expression
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^
3 | }
| ^
|
...
help: try adding braces
|
2 ~ let _x = Box::new(|x| {x+1;);
3 ~ }}
...
error: expected `;`, found `}`
--> ./main.rs:2:32
|
2 | let _x = Box::new(|x|x+1;);
| ^ help: add `;` here
3 | }
| - unexpected token
error: aborting due to 3 previous errors
```
This commit allows outputting correct suggestions and errors. The above
code would output like this:
```
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^ ^
|
note: statement found outside of a block
--> ./main.rs:2:29
|
2 | let _x = Box::new(|x|x+1;);
| ---^ this `;` turns the preceding closure into a statement
| |
| this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
--> ./main.rs:2:23
|
2 | let _x = Box::new(|x|x+1;);
| ^^^^^^ - ...but likely you meant the closure to end here
| |
| this is the parsed closure...
help: try adding braces
|
2 | let _x = Box::new(|x| {x+1;});
| + +
error: aborting due to previous error
```
|
|
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
|
|
|
|
|
|
|
|
|
|
This commit changes the sequence parsers to produce `ThinVec`, which
triggers numerous conversions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suggest fix for misplaced generic params on fn item #103366
fixes #103366
This still has some work to go, but works for 2/3 of the initial base cases described in #1033366
simple fn:
```
error: expected identifier, found `<`
--> shreys/test_1.rs:1:3
|
1 | fn<T> id(x: T) -> T { x }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn id<T>(x: T) -> T { x }
| ~~~~
```
Complicated bounds
```
error: expected identifier, found `<`
--> spanishpear/test_2.rs:1:3
|
1 | fn<'a, B: 'a + std::ops::Add<Output = u32>> f(_x: B) { }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn f<'a, B: 'a + std::ops::Add<Output = u32>>(_x: B) { }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Opening a draft PR for comments on approach, particularly I have the following questions:
- [x] Is it okay to be using `err.span_suggestion` over struct derives? I struggled to get the initial implementation (particularly the correct suggestion message) on struct derives, although I think given what I've learned since starting, I could attempt re-doing it with that approach.
- [x] in the case where the snippet cannot be obtained from a span, is the `help` but no suggestion okay? I think yes (also, when does this case occur?)
- [x] are there any red flags for the generalisation of this work for relevant item kinds (i.e. `struct`, `enum`, `trait`, and `union`). My basic testing indicates it does work for those types except the help tip is currently hardcoded to `after the function name` - which should change dependent on the item.
- [x] I am planning to not show the suggestion if there is already a `<` after the item identifier, (i.e. if there are already generics, as after a function name per the original issue). Any major objections?
- [x] Is the style of error okay? I wasn't sure if there was a way to make it display nicer, or if thats handled by span_suggestion
These aren't blocking questions, and I will keep working on:
- check if there is a `<` after the ident (and if so, not showing the suggestion)
- generalize the help message
- figuring out how to write/run/etc ui tests (including reading the docs for them)
- logic cleanups
|
|
Migrate some of `rustc_parse` to derive diagnostics
`@rustbot` label +A-translation
r? rust-lang/diagnostics
cc #100717
|
|
|
|
|
|
lenko-d:default_value_for_a_lifetime_generic_parameter_produces_confusing_diagnostic, r=compiler-errors
Recover from lifetimes with default lifetimes in generic args
Fixes [#107492](https://github.com/rust-lang/rust/issues/107492)
|
|
|
|
|
|
|
|
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``
|
|
Parse and recover from type ascription in patterns
Reintroduce part of #106960, which was reverted in #107478.
r? `@compiler-errors`
|
|
This makes it clear they return token trees, and makes for a nice
comparison against `TokenCursor` which returns tokens.
|
|
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.
|
|
|
|
Sometimes the parser needs to desugar a doc comment into `#[doc =
r"foo"]`. Currently it does this in a hacky way: by pushing a "fake" new
frame (one without a delimiter) onto the `TokenCursor` stack.
This commit changes things so that the token stream itself is modified
in place. The nice thing about this is that it means
`TokenCursorFrame::delim_sp` is now only `None` for the outermost frame.
|
|
|
