facepalm Trailing closures really need to be tied to the syntactic form of the callee, neither of those should be allowed IMO.

Perhaps for Swift 6...

-Chris

Just to contribute another test case: `foo {} () {}` parses

@swift-ci create

Comment by Daniel Sweeney (JIRA)

I've been looking at this a little. Dumping the parse of both of the bad forms above comes out as

        (call_expr 
          (call_expr 
            (paren_expr trailing-closure))
          (paren_expr trailing-closure)) 

(eliding some stuff in the tree).

If you checked when the second trailing-closure is parsed whether you were in the matching structure (with a call_expr/paren=trailing closure sibling in the call_expr you belong to, oversimplified) you could catch both the syntax problems above.

I was trying to figure out how to do this in code though. SwiftParse/ParseExpr.cpp/ParseExprList is where it parses the trailing closure but that does not feel like the right place in code–other places in SwiftParse don't seem to be matching on structure to find things (I might be wrong) unless they are looking immediately forward in the parse stream.

Is there someplace where it would make sense to put this check? It feels like something that makes sense in the type checker but it's checking syntax. Or am I worrying about it too much?

Comment by Daniel Sweeney (JIRA)

I put together a pull request for this: #32000 .

Comment by Daniel Sweeney (JIRA)

I closed the pull request for now. We can open it back up at some point if we decide about the source-breaking change. I'm going to un-assign this as well, but I can take it back on.

Thanks dfsweeney (JIRA User)! I'll see if I can get the core team to make a decision on this in one of our meetings soon.