[Parse] Split declaration list parsing from parseList()

[rintaro]

Parsing declaration list (e.g. member list of nominal decl) is very
different from comma separated list, because their elements are separated with
new-line or semi-colon. There's no good reason to consolidate them.

Also, declaration list in extension or inside of decl #if didn't properly diagnose
consecutive declarations on a line. This code used to be successfully compiled.

class C {
#if true
  var value: Int = 42 func foo() {}
#endif
}
extension C {
  func bar() {} subscript(i: Int) -> Int {
    return 24
  }
}

This PR unifies declaration list parsing for
members of nominal decls, extensions, and inside of #if.

In addition, removed unnecessary property TrailingSemiLoc from Decl, Stmt, and Expr.

[jrose-apple]

I'd like @bitjammer to weigh in on removing these, given that he's working towards preserving more source information. Would these just become "trivia", like comments and whitespace?

[bitjammer]

Kind of a gray area, similar to escaping backticks, but we can keep track of things like this in the syntax tree.

[bitjammer]

I'd prefer not to remove source information from the current nodes if it's not going to get observed during parse. Also, if you are going to use consumeToken() call, please either comment what you are consuming, or use consumeToken(tok::_____) to indicate what you are expecting to drop. But I would prefer not to drop source information right now.

[rintaro]

I'm OK to preserve TrailingSemiLocs. But I think we have a problem in the current implementation.

For example, on let (a, b) = (1, 2), the parser produces 3 decls in this order:

      (pattern_binding_decl
        (pattern_tuple (pattern_named 'a') (pattern_named 'b'))
        (tuple_expr ...)
      (var_decl "a")
      (var_decl "b")

The current master implementation attaches TrailingSemiLoc only to the last (var_decl "b") which is not relevant, I think. It should be the pattern_binding_decl.

Fixing this is not trivial. If you are OK, I will do that in another PR.
Sounds good? @bitjammer

[jrose-apple]

I'm sad to lose these errors. I think they're for people who have a brain flutter and think } will close #if. It might be worth the improvement, though.

[rintaro]

I removed this error because it makes me feel that this #if block was implicitly terminated by the parser.
Probably, we should emit a specialized error for this, something like unexpected '}' in conditional compilation block or conditional compilation blocks must surround self-contained statements.
How do you think?

[jrose-apple]

Okay, that's fair (and can be added separately).

[slavapestov]

@rintaro Do you mind rebasing this?

@jrose-apple Does this LGTY?

[rintaro]

@swift-ci Please smoke test

[jrose-apple]

Still delegating to @bitjammer (about the whole patch).

[bitjammer]

Looking.

[bitjammer]

LGTM.

[rintaro]

Thank you for reviewing! Can I merge this before merging master to 3.1?

[jrose-apple]

I'm not sure if merging now makes the 3.1 branch or not, but if @bitjammer is comfortable with it for 3.1 as well it can be cherry-picked over. Note that we are in "strict mode" now so please follow the template.