[Syntax] Parse: add support for TupleType and FunctionType

[rintaro]

For now, using SyntaxParsingContext.
CC: @nkcsgexi

[rintaro]

@swift-ci Please smoke test

[rintaro]

Since I declared rich TupleTypeElement, use TupleTypeElementList here instead of FunctionTypeArgumentList.
Removed FunctionTypeArgument(List)

[rintaro]

We should use isTypeKind(Kind) API et al here (instead of name based heuristics).
E.g. SimpleTypeIdentifier is Type kind.
TODO for follow up PR.

[nkcsgexi]

Minor comments/questions inline.

[nkcsgexi]

If we are using Initializer, can we refactor the part in FunctionParameter to initializer too? they are now equal+expr.

[rintaro]

Sure thing. I'll do that in follow up PR 👍

[nkcsgexi]

Could you clarify why do we need this? If a FunctionType node is already created, the parent context will do nothing if the FunctionType is the only node. setTransparent will disallow the creation of an UnknownType wrapper if there are other nodes; is this why we need it here?

[rintaro]

The structure here is something like this:

func parseTypeTupleBody() {
  SyntaxContextRAII(SyntaxContext)
  consumeToken(tok::l_paren) // '('
  parseTupleTypeElementList() // tuple-type-element-list
  consumeToken(tok::r_paren) // ')'
   
  isFunctionType = tok.isAny(tok::arrow, tok::throws)
  if isFunctionType {
    // propagate to the parent stack.
    SyntaxContext.setTransparent()
  } else {
    //  '(' tuple-type-element-list ')'
    SyntaxContext.setCreate(SyntaxKind::TupleType)
  }
}

func parseType() {
  SyntaxContextRAII(SyntaxContext)
  parseTypeTupleBody()
   
  isFunctionType = tok.isAny(tok::arrow, tok::throws)
  if (isFunctionType) {
    consumeIf(tok::kw_throws) // 'throws'
    consumeToken(tok::arrow) // '->'
    parseType() // return type

    // '(' tuple-type-element-list ')' 'throws'? '->' type
    Context.setCreateType(SyntaxKind::FunctionType)
  } else {
    // type | unknown-type 
    Context.setCoerce(ContextKind::Type)
  }
}

If we see -> or throws after r_paren, we have to propagate '(' tuple-type-element-list ')' part back to parseType()

[nkcsgexi]

I see. Thank you for explaining! could we add some comments there to keep track of this scope-misalignment?

[nkcsgexi]

Thinking a little bit more about this, how about we make the first three children of a FunctionType a TupleType? This allows us to get rid of setTransparent and to simplify the structure of FunctionType.

[rintaro]

Hmm, although that's convenient solution for now, I'd like to avoid that because it's against @CodaFi's efforts of re-modeling function type parameters.
How about to parse just TypeTuple in parseTypeTupleBody, then decompose it to '(' TupleTypeElementList ')' and repack into FunctionType in parseType?

[nkcsgexi]

that'll add another operation (decompose) to SyntaxParsingContext, right? If changing function type's structure isn't a good option, i'd say what you have for now is good enough.

[rintaro]

that'll add another operation (decompose) to SyntaxParsingContext, right?

Not really. We can SyntaxParsingContext::popIf(), build FunctionType with FunctionTypeSyntaxBuilder, then SyntaxParsingContext::addSyntax().

[rintaro]

@swift-ci Please smoke test