| Age | Commit message (Collapse) | Author | Lines |
|
Stabilise `feature(const_generics_defaults)`
`feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation.
needs stabilisation report and maybe an RFC :sweat_smile:
r? `@lcnr`
cc `@rust-lang/project-const-generics`
|
|
Remove redundant [..]s
|
|
|
|
Do not attempt to suggest help for overly malformed struct/function call
This fixes: https://github.com/rust-lang/rust/issues/91461
|
|
|
|
Add a suggestion if `macro_rules` is misspelled
Fixes #91227.
|
|
|
|
r=estebank
Do not add `;` to expected tokens list when it's wrong
There's a few spots where semicolons are checked for to do error recovery, and should not be suggested (or checked for other stuff).
Fixes #87647
|
|
Also add a test case for inserting a semicolon on extern fns.
Without this fix, we got an error like this:
error: expected one of `->`, `where`, or `{`, found `}`
--> chk.rs:3:1
|
2 | fn foo()
| --- - expected one of `->`, `where`, or `{`
| |
| while parsing this `fn`
3 | }
| ^ unexpected token
Since this is inside an extern block, you're required to write function
prototypes with no body. This fixes a regression, and adds a test case
for it.
|
|
|
|
Explain why `Self` is invalid in generic parameters
Close #89985.
r? `@estebank`
|
|
There's a few spots where semicolons are checked for to do error recovery,
and should not be suggested (or checked for other stuff).
Fixes #87647
|
|
Improve diagnostic for missing half of binary operator in `if` condition
Fixes #91421. I've also changed it so that it doesn't consume the `else` token in the error case, because it will try to consume it again afterwards, leading to this incorrect error message (where the `else` reported as missing is actually there):
```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
--> src/main.rs:4:12
|
4 | } else { 4 };
| ^ expected one of `.`, `;`, `?`, `else`, or an operator
```
r? `@lcnr`
|
|
|
|
expand: Turn `ast::Crate` into a first class expansion target
And stop creating a fake `mod` item for the crate root when expanding a crate, thus addressing FIXMEs left in https://github.com/rust-lang/rust/pull/82238, and making a step towards a proper support for crate-level macro attributes (cc #54726).
I haven't added token collection support for the whole crate in this PR, maybe later.
r? `@Aaron1011`
|
|
|
|
|
|
And stop creating a fake `mod` item for the crate root when expanding a crate.
|
|
|
|
Account for incorrect `impl Foo<const N: ty> {}` syntax
Fix #84946
|
|
|
|
Fix #84946
|
|
fix(doctest): detect extern crate items in statement doctests
This partially reverts #91026, because rustdoc needs to detect the extern statements, even when they appear inside implicit `main()`. It does not entirely revert it, so the old bug is still fixed, by duplicating some of the logic from `parse_mod` instead of trying to use it directly.
Fixes #91134
|
|
This partially reverts #91026, because rustdoc needs to detect the extern statements,
even when they appear inside implicit `main()`. It does not entirely revert it,
so the old bug is still fixed, by duplicating some of the logic from `parse_mod`
instead of trying to use it directly.
Fixes #91134
|
|
|
|
Fix ICE `#90993`: add missing call to cancel
Fix #90993
|
|
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
|
|
|
|
TraitKind -> Trait
TyAliasKind -> TyAlias
ImplKind -> Impl
FnKind -> Fn
All `*Kind`s in AST are supposed to be enums.
Tuple structs are converted to braced structs for the types above, and fields are reordered in syntactic order.
Also, mutable AST visitor now correctly visit spans in defaultness, unsafety, impl polarity and constness.
|
|
Give better error for `macro_rules name`
follow up to #89221
r? ``@estebank``
``@rustbot`` modify labels: +A-diagnostics +A-parser
|
|
|
|
rustc_span: `Ident::invalid` -> `Ident::empty`
The equivalent for `Symbol`s was renamed some time ago (`kw::Invalid` -> `kw::Empty`), and it makes sense to do the same thing for `Ident`s as well.
|
|
Nicer error message if the user attempts to do let...else if
Gives a nice "conditional `else if` is not supported for `let...else`" error when encountering a `let...else if` pattern, as suggested in the [let...else tracking issue](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205).
|
|
|
|
The equivalent for `Symbol`s was renamed some time ago (`kw::Invalid` -> `kw::Empty`), and it makes sense to do the same thing for `Ident`s.
|
|
|
|
|
|
|
|
|
|
|
|
feat(rustc_parse): recover from pre-RFC-2000 const generics syntax
Fixes #89013
|
|
Co-authored-by: Esteban Kuber <esteban@kuber.com.ar>
|
|
Give better error for `macro_rules! name!`
r? ``@estebank``
``@rustbot`` modify labels: +A-diagnostics +A-parser
|
|
|
|
Fix error recovery in format macro parsing
Fixes #88770. Basically, the assumption in the following comment is incorrect:
https://github.com/rust-lang/rust/blob/b69fe57261086e70aea9d5b58819a1794bf7c121/compiler/rustc_builtin_macros/src/format.rs#L167-L172
This is only true in the first iteration of the loop, when [`p.clear_expected_tokens()`](https://github.com/rust-lang/rust/blob/b69fe57261086e70aea9d5b58819a1794bf7c121/compiler/rustc_builtin_macros/src/format.rs#L164) is called. In subsequent iterations, `p.expected_tokens` won't be empty, so `p.expect()` won't actually call `unexpected_try_recover()`:
https://github.com/rust-lang/rust/blob/b69fe57261086e70aea9d5b58819a1794bf7c121/compiler/rustc_parse/src/parser/mod.rs#L487-L498
Instead, it will call `expect_one_of()`, which _can_ recover and return `Ok()`. This PR handles this case to fix the ICE in #88770.
|
|
Resolve issue : Somewhat confusing error with extended_key_value_attributes
Fixes #85066
|
|
"Fix" an overflow in byte position math
r? `@estebank`
help! I fixed the ICE only to brick the diagnostic.
I mean, it was wrong previously (using an already expanded macro span), but it is really bad now XD
|
|
|
|
Newcomers may write `{1, 2, 3}` for making arrays, and the current error
message is not informative enough to quickly convince them what is
needed to fix the error.
This PR implements a diagnostic for this case, and its output looks like
this:
```text
error: this code is interpreted as a block expression, not an array
--> src/lib.rs:1:22
|
1 | const FOO: [u8; 3] = {
| ______________________^
2 | | 1, 2, 3
3 | | };
| |_^
|
= note: to define an array, one would use square brackets instead of curly braces
help: try using [] instead of {}
|
1 | const FOO: [u8; 3] = [
2 | 1, 2, 3
3 | ];
|
```
Fix #87672
|
|
Fix : use struct_dummy
Fix different os messages
|