parse: fuse associated and extern items up to defaultness

[Centril]

Language changes:

• The grammar of extern type aliases is unified with associated ones, and becomes:

  TypeItem = "type" ident generics {":" bounds}? where_clause {"=" type}? ";" ;

  Semantic restrictions (ast_validation) are added to forbid any parameters in generics, any bounds in bounds, and any predicates in where_clause, as well as the presence of a type expression (= u8).

  (Work still remains to fuse this with free type aliases, but this can be done later.)

• The grammar of constants and static items (free, associated, and extern) now permits the absence of an expression, and becomes:

  GlobalItem = {"const" {ident | "_"} | "static" "mut"? ident} {"=" expr}? ";" ;

  • A semantic restriction is added to enforce the presence of the expression (the body).
  • A semantic restriction is added to reject const _ in associated contexts.

Together, these changes allow us to fuse the grammar of associated items and extern items up to defaultness which is the main goal of the PR.

---

We are now very close to fully fusing the entirely of item parsing and their ASTs. To progress further, we must make a decision: should we parse e.g. default use foo::bar; and whatnot? Accepting that is likely easiest from a parsing perspective, as it does not require using look-ahead, but it is perhaps not too onerous to only accept it for fns (and all their various qualifiers), consts, statics, and types.

r? @petrochenkov

[petrochenkov]

The grammar of extern items now recognize const items.
The grammar of associated items now recognize static items.

This is excessive, IMO.
The goal is unify with free items as well, does that mean we'll syntactically accept e.g. struct inside traits or extern blocks? I don't think so.
We can parse them (for better diagnostics) while still issuing immediate errors in the parser.

[Centril]

Fair, but if we want to unify the parsing functions, we need to at least make the AST changes so that the *Kinds can be merged. I'll move the respective errors from validation to parsing as a "filtering" step.

[petrochenkov]

Here's how I see the end state here

enum ItemKind {
    Fn(FnCommon),
    Const(ConstCommon),
    TyAlias(TyAliasCommon),
    Mac(MacCommon),
    Static(StaticCommon),
    ... // Others
}

enum AssocItemKind {
    Fn(FnCommon),
    Const(ConstCommon),
    TyAlias(TyAliasCommon),
    Mac(MacCommon),
}

enum ForeignItemKind {
    Fn(FnCommon),
    TyAlias(TyAliasCommon),
    Mac(MacCommon),
    Static(StaticCommon),
}

, modulo the *Common naming.

All *Common things share data structures and parsing code, but ItemKind, AssocItemKind and ForeignItemKind are still different enums because they support different subsets of items inside them at parse time (at least in the near future).

[petrochenkov]

Basically we can use a parse_item routine for free items in all cases, but then filter and re-package its results.

[Centril]

I would much prefer to have a single ItemKind and do filtering on that as opposed to repackaging, as I think that will lead to more code sharing in terms of pretty printing, visitors, and whatnot compared to having different kinds (and thus needing matches for each form in terms of visiting, pprust, etc.).

At any rate, it would be easiest to move towards merging into ItemKind and then diverge later than to try to add those *Common structs "in-flight".

[petrochenkov]

@Centril

I think that will lead to more code sharing in terms of pretty printing, visitors, and whatnot

Not significantly, it's basically an extra match function in printing, visitors, parsing and lowering, but instead we do not keep syntactically impossible state in AST. Yes, it doesn't allow to reduce code to absolute minimum, but on the other hand it would be nice to keep AST in check a bit in terms of its closeness to the language.

[petrochenkov]

@bors r+

[bors]

📌 Commit 045b7d5 has been approved by petrochenkov