-
Notifications
You must be signed in to change notification settings - Fork 19
Update for new stable and unstable features, and fix a few mistakes. #68
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything seems to look good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome
now it's just fixing the CI then we're good to go |
CI failure is just a required snapshot update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are probably more things that need to be tweaked, but here are some corrections.
@@ -125,6 +127,6 @@ ElseExpr = | |||
| If:If | |||
; | |||
|
|||
MatchArm = attrs:OuterAttr* "|"? pats:Pat+ % "|" { "if" guard:Expr }? "=>" body:Expr ","?; | |||
MatchArm = attrs:OuterAttr* "|"? pat:Pat { "if" guard:Expr }? "=>" body:Expr ","?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to this setup, where nested or-patterns are unstable, then match 0 { 0 | 1 => 0 }
is also unstable but it isn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a proper stability setup, but I can undo this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just leave a comment instead. You might want to double check if/while let
also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we annoyingly don't allow fn foo(Ok(x) | Err(x): _);
but require parens around the pattern instead.
; | ||
// unstable(c_variadic): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The syntax itself is stable so you can remove this.
| SelfValue:{ mutable:"mut"? "self" } | ||
| SelfRef:{ "&" lt:LIFETIME? mutable:"mut"? "self" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The self
param is only allowed in the first parameter syntactically (Also, consider lifting this out to its own rule.)
| CVariadic:FnCVariadicParam | ||
| RegularAndCVariadic:{ args:FnParam+ % "," "," c_variadic:FnCVariadicParam } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...
is allowed in any position now syntactically with semantic restrictions in validation to enforce the order (I fixed your FIXME.)
; | ||
// unstable(c_variadic): | ||
FnCVariadicParam = attrs:OuterAttr* { pat:Pat ":" }? "..."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's more like this:
FnParamKind =
| SelfParam: FnSelfParam
| Regular:{ { pat:Pat ":" }? ty:FnParamType }
;
FnParamType =
| CVariadic: "..."
| Regular: Type
;
| RangeInclusive:{ | ||
| start:PatRangeValue { "..." | "..=" } end:PatRangeValue | ||
// unstable(half_open_range_patterns): | ||
| { "..." | "..=" } end:PatRangeValue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| { "..." | "..=" } end:PatRangeValue | |
| "..=" end:PatRangeValue |
| Slice:{ "[" elems:SlicePatElem* %% "," "]" } | ||
| Tuple:{ "(" fields:TuplePatField* %% "," ")" } | ||
// unstable(or_patterns): | ||
// FIXME(eddyb) find a way to express "2 or more" (like regex `{2,}`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively you can just explain this as a binary operator rather than a list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair, it's just weird to think of it as a binary operator because it's fully commutative and associative.
FnSigInputs = | ||
| Regular:FnSigInput+ %% "," | ||
| Variadic:"..." | ||
| RegularAndVariadic:{ inputs:FnSigInput+ % "," "," "..." } | ||
| CVariadic:FnSigCVariadicInput | ||
| RegularAndCVariadic:{ inputs:FnSigInput+ % "," "," c_variadic:FnSigCVariadicInput } | ||
; | ||
FnSigInput = { pat:Pat ":" }? ty:Type; | ||
FnSigInput = attrs:OuterAttr* { pat:Pat ":" }? ty:Type; | ||
FnSigCVariadicInput = attrs:OuterAttr* "..."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't right; the actual grammar is defined by:
fn parse_ty_bare_fn(&mut self, generic_params: Vec<GenericParam>) -> PResult<'a, TyKind> {
let unsafety = self.parse_unsafety();
let ext = self.parse_extern()?;
self.expect_keyword(kw::Fn)?;
let decl = self.parse_fn_decl(|_| false, AllowPlus::No)?;
Ok(TyKind::BareFn(P(BareFnTy { ext, unsafety, generic_params, decl })))
}
Aside from that false
, which adjusts the precedence (bias towards named vs. not), its just the regular FnDecl
grammar, and since we don't deal with precedence here, you can use FnDecl
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I'd rather move the full grammar here than have a separate FnDecl
, but that makes sense.
So fn(self)
parses, I didn't know that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I've made some changes recently in the large scale parser refactorings to simplify things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to review the new tests and PR descriptions in:
- parse: unify item parsing & filter illegal item kinds rust#69366
- parse: allow
type Foo: Ord
syntactically rust#69361 - parse: fuse associated and extern items up to defaultness rust#69194
- parse: unify function front matter parsing rust#69023
- parse: towards unified
fn
grammar rust#68788 - parser: syntactically allow
self
in allfn
contexts rust#68764 - parse: merge
fn
syntax + cleanup item parsing rust#68728 - Merge
TraitItem
&ImplItem into
AssocItem` rust#67131
On rust-lang/rust@b9d5ee5 (w/o submodules), out of a total of 13964 files:
I haven't updated
external/rust
to rust-lang/rust@b9d5ee5, only locally, let me know if I should.const_generics
)c_variadic
)unsafe
andasync
)..
) #64 (rest patterns)