| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stabilize `async_await` in Rust 1.39.0
Here we stabilize:
- free and inherent `async fn`s,
- the `<expr>.await` expression form,
- and the `async move? { ... }` block form.
Closes https://github.com/rust-lang/rust/issues/62149.
Closes https://github.com/rust-lang/rust/issues/50547.
All the blockers are now closed.
<details>
- [x] FCP in https://github.com/rust-lang/rust/issues/62149
- [x] https://github.com/rust-lang/rust/issues/61949; PR in https://github.com/rust-lang/rust/pull/62849.
- [x] https://github.com/rust-lang/rust/issues/62517; PR in https://github.com/rust-lang/rust/pull/63376.
- [x] https://github.com/rust-lang/rust/issues/63225; PR in https://github.com/rust-lang/rust/pull/63501
- [x] https://github.com/rust-lang/rust/issues/63388; PR in https://github.com/rust-lang/rust/pull/63499
- [x] https://github.com/rust-lang/rust/issues/63500; PR in https://github.com/rust-lang/rust/pull/63501
- [x] https://github.com/rust-lang/rust/issues/62121#issuecomment-506884048
- [x] Some tests for control flow (PR https://github.com/rust-lang/rust/pull/63387):
- `?`
- `return` in `async` blocks
- `break`
- [x] https://github.com/rust-lang/rust/pull/61775#issuecomment-506883180, i.e. tests for https://github.com/rust-lang/rust/pull/60944 with `async fn`s instead). PR in https://github.com/rust-lang/rust/pull/63383
</details>
r? @cramertj
|
|
|
|
|
|
|
|
Normalize newlines when loading files
Fixes #62865
|
|
Initial implementation of or-patterns
An incomplete implementation of or-patterns (e.g. `Some(0 | 1)` as a pattern). This patch set aims to implement initial parsing of `or-patterns`.
Related to: #54883
CC @alexreg @varkor
r? @Centril
|
|
|
|
Initial implementation of parsing or-patterns e.g., `Some(Foo | Bar)`.
This is a partial implementation of RFC 2535.
|
|
|
|
We now store it in the `Span` of the expression or item.
|
|
Feature gate 'yield $expr?' pre-expansion
Also improve the overall ergonomics of pre-expansion gating in general.
r? @Zoxc
|
|
|
|
|
|
Make sure that all file loading happens via SourceMap
That way, callers don't need to repeat "let's add this to sm manually
for tracking dependencies" trick.
It should make it easier to switch to using `FileLoader` for binary
files in the future as well
cc #62948
r? @petrochenkov
|
|
For naming consistency with everything else in this area
|
|
It was introduced to avoid going through `hygiene_data`, but now it's read only once, when `ParseSess` is created, so going through a lock is ok.
|
|
|
|
The expansion info is not optional and should always exist
|
|
`Ident` has had a full span rather than just a `SyntaxContext` for a long time now.
|
|
For consistency with `ExpnId::root`.
Also introduce a helper `Span::with_root_ctxt` for creating spans with `SyntaxContext::root()` context
|
|
|
|
|
|
|
|
|
|
That way, callers don't need to repeat "let's add this to sm manually
for tracking dependencies" trick.
It should make it easier to switch to using `FileLoader` for binary
files in the future as well
|
|
Merge Variant and Variant_
Extracted from #63468.
|
|
Add NodeId for Arm, Field and FieldPat
Extracted from #63468
|
|
expand: Unimplement `MutVisitor` on `MacroExpander`
Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention.
It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass.
So, it shouldn't hide under a generic visitor call.
Also, from all the implemented visitor methods only two were actually used.
cc https://github.com/rust-lang/rust/pull/63468#discussion_r313504119
|
|
syntax: Remove `DummyResult::expr_only`
The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported.
This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments.
(There wasn't even a test making sure it worked.)
Addresses https://github.com/rust-lang/rust/pull/63468#discussion_r313504644
r? @estebank
|
|
libsyntax: cleanup and refactor `pat.rs`
A smaller refactoring & cleanup of `pat.rs` (best read commit by commit).
r? @petrochenkov
|
|
Add lint for excess trailing semicolons
Closes #60876.
A caveat (not necessarily a negative, but something to consider) with this implementation is that excess semicolons after return/continue/break now also cause an 'unreachable statement' warning.
For the following example:
```
fn main() {
extra_semis();
}
fn extra_semis() -> i32 {
let mut sum = 0;;;
for i in 0..10 {
if i == 5 {
continue;;
} else if i == 9 {
break;;
} else {
sum += i;;
}
}
return sum;;
}
```
The output is:
```
warning: unnecessary trailing semicolons
--> src/main.rs:5:21
|
5 | let mut sum = 0;;;
| ^^ help: remove these semicolons
|
= note: `#[warn(redundant_semicolon)]` on by default
warning: unnecessary trailing semicolon
--> src/main.rs:8:22
|
8 | continue;;
| ^ help: remove this semicolon
warning: unnecessary trailing semicolon
--> src/main.rs:10:19
|
10 | break;;
| ^ help: remove this semicolon
warning: unnecessary trailing semicolon
--> src/main.rs:12:22
|
12 | sum += i;;
| ^ help: remove this semicolon
warning: unnecessary trailing semicolon
--> src/main.rs:15:16
|
15 | return sum;;
| ^ help: remove this semicolon
warning: unreachable statement
--> src/main.rs:8:22
|
8 | continue;;
| ^
|
= note: `#[warn(unreachable_code)]` on by default
warning: unreachable statement
--> src/main.rs:10:19
|
10 | break;;
| ^
warning: unreachable statement
--> src/main.rs:15:16
|
15 | return sum;;
| ^
```
|
|
|
|
|
|
Fix typo in error message.
|
|
Do not ICE when synthesizing spans falling inside unicode chars
Fix https://github.com/rust-lang/rust/issues/61226.
|
|
Bring back suggestion for splitting `<-` into `< -`
Closes #62632
|
|
syntax: account for CVarArgs being in the argument list.
Fixes #63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.
Note that the error has basically been impossible to trigger since the change that caused #63430, so perhaps we need an audit of untested errors.
Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.
r? @petrochenkov cc @dlrobertson
|
|
|
|
Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention.
It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass.
So, it shouldn't be hide under a generic visitor call.
Also, from all the implemented visitor methods only two were actually used.
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
