Skip to content
This repository has been archived by the owner on Apr 8, 2024. It is now read-only.

Update for new stable and unstable features, and fix a few mistakes. #68

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Mar 29, 2020

On rust-lang/rust@b9d5ee5 (w/o submodules), out of a total of 13964 files:

Before After Δ
1043 1045 +2 parsed fully and unambiguously
12221 12534 +313 parsed fully (but ambiguously)
613 298 -315 parsed partially (only a prefix)
87 87 0 didn't parse at all (lexer error?)

I haven't updated external/rust to rust-lang/rust@b9d5ee5, only locally, let me know if I should.


Copy link
Contributor

@CAD97 CAD97 left a 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.

Copy link
Member

@qmx qmx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

awesome

@qmx
Copy link
Member

qmx commented Mar 29, 2020

now it's just fixing the CI then we're good to go

@CAD97
Copy link
Contributor

CAD97 commented Mar 29, 2020

CI failure is just a required snapshot update.

Copy link
Contributor

@Centril Centril left a 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 ","?;
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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):
Copy link
Contributor

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.

Comment on lines 99 to 100
| SelfValue:{ mutable:"mut"? "self" }
| SelfRef:{ "&" lt:LIFETIME? mutable:"mut"? "self" }
Copy link
Contributor

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.)

Comment on lines +94 to +95
| CVariadic:FnCVariadicParam
| RegularAndCVariadic:{ args:FnParam+ % "," "," c_variadic:FnCVariadicParam }
Copy link
Contributor

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 ":" }? "...";
Copy link
Contributor

@Centril Centril Mar 30, 2020

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
   ;

grammar/pat.lyg Show resolved Hide resolved
| RangeInclusive:{
| start:PatRangeValue { "..." | "..=" } end:PatRangeValue
// unstable(half_open_range_patterns):
| { "..." | "..=" } end:PatRangeValue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| { "..." | "..=" } 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,}`).
Copy link
Contributor

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.

Copy link
Member Author

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.

Comment on lines 22 to +28
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* "...";
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

@Centril Centril Mar 30, 2020

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants