| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
address some FIXME whose associated issues were marked as closed
part of #44366
|
|
Rollup of 17 pull requests
- Successful merges: #46518, #48810, #48834, #48902, #49004, #49092, #49096, #49099, #49104, #49125, #49139, #49152, #49157, #49161, #49166, #49176, #49184
- Failed merges:
|
|
Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`
|
|
improve error message of inner attribute syntax
Fixes #49040
|
|
|
|
|
|
|
|
|
|
syntax: Make imports in AST closer to the source and cleanup their parsing
This is a continuation of https://github.com/rust-lang/rust/pull/45846 in some sense.
|
|
Fix spans of root segments
|
|
|
|
Add the root segment for name resolution purposes only
|
|
Fix `unused_import_braces` lint false positive on `use prefix::{self as rename}`
|
|
|
|
|
|
|
|
|
|
Make CodeMap and FileMap thread-safe
r? @michaelwoerister
|
|
Rollup of 17 pull requests
- Successful merges: #48706, #48875, #48892, #48922, #48957, #48959, #48961, #48965, #49007, #49024, #49042, #49050, #48853, #48990, #49037, #49049, #48972
- Failed merges:
|
|
Implement import renaming with `_` (RFC 2166)
cc https://github.com/rust-lang/rust/issues/48216
|
|
They are disallowed because they have different precedence than
expressions. I assume parenthesis in pattern will be soon stabilized and
thus write that as suggestion directly.
|
|
|
|
|
|
|
|
(Meanwhile, a couple of parse-fail tests are moved to UI tests so that
the reader can see the new output, and an existing UI test is given a
more evocative name.)
|
|
Warn about ignored generic bounds in `for`
This adds a new lint to fix #42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Cc @eddyb
|
|
r=estebank
in which parentheses are suggested for should-have-been-tuple-patterns
Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.
Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
`let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of `parse_full_stmt`).
Instead, let's look for that comma when parsing the pattern, and if we
see it, make-believe that we're parsing the remaining elements in a
tuple pattern, so that we can suggest wrapping it all in parentheses. We
need to do this in a separate wrapper method called on a "top-level"
pattern, rather than within
`parse_pat` itself, because `parse_pat` gets called recursively to parse
the sub-patterns within a tuple pattern.
~~We could also do this for `match` arms, `if let`, and `while let`, but
we elect not to in this patch, as it seems less likely for users to make
the mistake in those contexts.~~
Resolves #48492.
r? @petrochenkov
|
|
Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.
Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
`let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of `parse_full_stmt`).
Instead, let's look for that comma when parsing the pattern, and if we
see it, momentarily make-believe that we're parsing the remaining
elements in a tuple pattern, so that we can suggest wrapping it all in
parentheses. We need to do this in a separate wrapper method called on
the top-level pattern (or `|`-patterns) in a `let` statement, `for`
loop, `if`- or `while let` expression, or match arm rather than within
`parse_pat` itself, because `parse_pat` gets called recursively to parse
the sub-patterns within a tuple pattern.
Resolves #48492.
|
|
|
|
|
|
Also move the check for not having type parameters into ast_validation.
I was not sure what to do with compile-fail/issue-23046.rs: The issue looks like
maybe the bounds actually played a role in triggering the ICE, but that seems
unlikely given that the compiler seems to entirely ignore them. However, I
couldn't find a testcase without the bounds, so I figured the best I could do is
to just remove the bounds and make sure at least that keeps working.
|
|
Raw string error note
Fixes #48395.
I think this note should be helpful enough to solve the issue.
|
|
Fix spelling s/casted/cast/
r? @GuillaumeGomez
|
|
|
|
Fixes #47311.
r? @nrc
|
|
|
|
|
|
Improve recovery for trailing comma after `..`
|
|
|
|
|
|
When unnecessarily using a fat arrow after an if condition, suggest the
removal of it.
When finding an if statement with no block, point at the `if` keyword to
provide more context.
|
|
When finding:
```rust
match &Some(3) {
&None => 1
&Some(2) => { 3 }
_ => 2
}
```
provide the following diagnostic:
```
error: expected one of `,`, `.`, `?`, `}`, or an operator, found `=>`
--> $DIR/missing-comma-in-match.rs:15:18
|
X | &None => 1
| -- - help: missing comma
| |
| while parsing the match arm starting here
X | &Some(2) => { 3 }
| ^^ expected one of `,`, `.`, `?`, `}`, or an operator here
```
|
|
macros: improve struct constructor field hygiene, fix span bug
Fixes #47311.
r? @nrc
|
|
Implement multiple patterns with `|` in `if let` and `while let` (RFC 2175)
cc https://github.com/rust-lang/rust/issues/48215
|
|
Allow parentheses in `dyn (Trait)`
r? @eddyb @nikomatsakis
|
|
Fix parsing of extern paths in types and poly-traits
Fixes https://github.com/rust-lang/rust/issues/48262
|
|
When encountering invalid token after `unsafe`, mention `{`
Fix #37158.
|
|
|
