Stream: t-compiler/wg-rls-2.0

Topic: parsing traits, types and generic parameters


vipentti (Mar 25 2019 at 10:21, on Zulip):

Attempting to figure out where types & traits are actually allowed in rust, and figuring out how we are currently parsing things.

For example in Box<T + 'f>, is there a reason the parsed PathType contains the lifetime, rather than it being another separate item.

Currently this looks like:

PATH_TYPE@[12; 23)
  PATH@[12; 23)
    PATH_SEGMENT@[12; 23)
      NAME_REF@[12; 15)
        IDENT@[12; 15) "Box"
      TYPE_ARG_LIST@[15; 23)
        L_ANGLE@[15; 16)
        TYPE_ARG@[16; 22)
          PATH_TYPE@[16; 22)
            PATH@[16; 17)
              PATH_SEGMENT@[16; 17)
                NAME_REF@[16; 17)
                  IDENT@[16; 17) "T"
            WHITESPACE@[17; 18)
            PLUS@[18; 19)
            WHITESPACE@[19; 20)
            LIFETIME@[20; 22) "'f"
        R_ANGLE@[22; 23)

I would expect it probably to be something like:

    ...
        TYPE_ARG@[16; 22)
          PATH_TYPE@[16; 22)
            PATH@[16; 17)
              PATH_SEGMENT@[16; 17)
                NAME_REF@[16; 17)
                  IDENT@[16; 17) "T"
        WHITESPACE@[17; 18)
        PLUS@[18; 19)
        WHITESPACE@[19; 20)
        TYPE_ARG@...:
          LIFETIME@[20; 22) "'f"
        R_ANGLE@[22; 23)

With the LIFETIME being outside the PATH_TYPE.

Once I figure out where things are actually allowed, I'd like to attempt to fix the parser and maybe add some additional grammar for types/traits if it makes sense.parsing traits, types and generic parameters

matklad (Mar 25 2019 at 10:36, on Zulip):

So this is the confusing example. This is actually Box<dyn T + 'f>, and +'f is a part of a dyn type

matklad (Mar 25 2019 at 10:36, on Zulip):

in dyn, the first component is restricted to be a path, referring to the trait

vipentti (Mar 25 2019 at 10:37, on Zulip):

aha!

matklad (Mar 25 2019 at 10:37, on Zulip):

and dyn being optional is what creates confustion here

vipentti (Mar 25 2019 at 10:37, on Zulip):

That makes sense

matklad (Mar 25 2019 at 10:39, on Zulip):

A similar case of type-trait confustion happens in impls

matklad (Mar 25 2019 at 10:40, on Zulip):

In impl X for Y and impl X, the X can be either a trait or a type

matklad (Mar 25 2019 at 10:40, on Zulip):

I wish we could make this separation precise on the grammar level

matklad (Mar 25 2019 at 10:42, on Zulip):

and .... this is probably the first time I myself uderstand what's going on here. The dyn is the key

vipentti (Mar 25 2019 at 10:45, on Zulip):

hmm, what about struct S<T: 'a + ?Sized + (Copy)> I imagine here the bounds should be flattened, currently the PathTypes are nested

vipentti (Mar 25 2019 at 10:46, on Zulip):

It gets even more confusing when you change where the lifetime is

vipentti (Mar 25 2019 at 10:48, on Zulip):

or if you add more bounds

matklad (Mar 25 2019 at 10:49, on Zulip):

So, Trait1 + Trait2 + lifetime1 + lifetime2 is a TraitGroup

matklad (Mar 25 2019 at 10:49, on Zulip):

the syntax for dyn types is dyn: TraitGroup

matklad (Mar 25 2019 at 10:49, on Zulip):

dyn TraitGroup

matklad (Mar 25 2019 at 10:49, on Zulip):

the syntax for bound is Type: TraitGroup

matklad (Mar 25 2019 at 10:50, on Zulip):

and yeah, the TraitGroup should be flat

vipentti (Mar 25 2019 at 10:50, on Zulip):

I'll see about fixing it, after that where clauses should kinda work

vipentti (Mar 25 2019 at 10:51, on Zulip):

hmm, TraitGroup can contain Lifetime and TypeRef ?

matklad (Mar 25 2019 at 11:08, on Zulip):

yeah

vipentti (Mar 26 2019 at 06:46, on Zulip):

In trait T<U>: Hash + Clone where U: Copy {}, is Hash + Clone a TraitGroup as well ?

matklad (Mar 26 2019 at 06:52, on Zulip):

I think so!

vipentti (Mar 26 2019 at 07:00, on Zulip):

hmm, in trait X<U: Debug + Display> should the <U: Debug + Display> be parsed as:

TYPE_PARAM_LIST@[49; 69)
  L_ANGLE@[49; 50)
  TYPE_PARAM@[50; 68)
    NAME@[50; 51)
      IDENT@[50; 51) "U"
    COLON@[51; 52)
    WHITESPACE@[52; 53)
  TRAIT_GROUP.. // new
    PATH_TYPE@[53; 68)
      PATH@[53; 58)
        PATH_SEGMENT@[53; 58)
          NAME_REF@[53; 58)
            IDENT@[53; 58) "Debug"
    WHITESPACE@[58; 59)
    PLUS@[59; 60)
    WHITESPACE@[60; 61)
    PATH_TYPE@[61; 68)
      PATH@[61; 68)
          PATH_SEGMENT@[61; 68)
          NAME_REF@[61; 68)
              IDENT@[61; 68) "Display"

basically the typeparam list can contain the typeparam + optional trait group

matklad (Mar 26 2019 at 07:00, on Zulip):

I think : TraitGroup might be grouped under a Bound as well

matklad (Mar 26 2019 at 07:01, on Zulip):

It might also be a good idea to ping grammar WG on discord about naming and general structure in this area

matklad (Mar 26 2019 at 07:02, on Zulip):

IIRC, currently the gramamr closely mirrors what is implemented in rustc

matklad (Mar 26 2019 at 07:02, on Zulip):

but I think we can do much better here

vipentti (Mar 26 2019 at 07:03, on Zulip):

Yeah I think there is room for improvement

vipentti (Mar 30 2019 at 14:45, on Zulip):

Added a draft pr regarding this: https://github.com/rust-analyzer/rust-analyzer/pull/1077

Edwin Cheng (Apr 28 2019 at 06:13, on Zulip):

I am trying to implement default param in GenericParam, something like struct Foo<T=u8> {_v: T}. Currently it is parsed as :

STRUCT_DEF@[14; 45)
    STRUCT_KW@[14; 20) "struct"
    WHITESPACE@[20; 21) " "
    NAME@[21; 24)
      IDENT@[21; 24) "Foo"
    TYPE_PARAM_LIST@[24; 30)
      L_ANGLE@[24; 25) "<"
      TYPE_PARAM@[25; 29)
        NAME@[25; 26)
          IDENT@[25; 26) "T"
        EQ@[26; 27) "="
        PATH_TYPE@[27; 29)
          PATH@[27; 29)
            PATH_SEGMENT@[27; 29)
              NAME_REF@[27; 29)
                IDENT@[27; 29) "u8"
      R_ANGLE@[29; 30) ">"

Do we want to introduce another syntax node (something like DEFAULT_TYPE_PARAM) for that ? Or we can use that PATH_TYPE directly?

matklad (Apr 28 2019 at 12:28, on Zulip):

I think we don't need an extra node here

matklad (Apr 28 2019 at 12:28, on Zulip):

But we should definitelly add an default method to TypeParam

Edwin Cheng (Apr 28 2019 at 13:43, on Zulip):

My concern is that if we use PATH_TYPE, it will be confused with other syntax. If not, then it’s good. :+1:

matklad (Apr 28 2019 at 13:46, on Zulip):

As long as we have well-typed accessor methods on TypeParam, I think there won't be any confustion

Last update: Nov 12 2019 at 15:50UTC