Ah darn, thanks for finding the bug! Somehow I never thought to test default arguments when implementing @dynamicCallable.
Investigating quickly.

EDIT: The problem occurs even when default arguments (for both methods) are removed. So the problem seems unrelated to default arguments.

Interesting, removing the protocol Proto makes the crash go away:

// This doesn't crash.
@dynamicCallable
struct Struct {
  func dynamicallyCall(withArguments args: [Struct] = []) {}
  func dynamicallyCall(withKeywordArguments args: DictionaryLiteral<String, Struct> = [:]) -> Struct {
    return Struct()
  }
}

func crasher() {
  let a = Struct()
  a(a(a, key: a))
}

Incidentally, I lean towards the opinion that default arguments on dynamicallyCall methods should be disabled.
Implicitly, dynamic calls already have a default argument: [] for the withArguments: method and [:] for the withKeywordArguments: method.

This is just the natural behavior:

@dynamicCallable
struct Callable {
  func dynamicallyCall(withArguments: [Int]) {}
}
let c = Callable()
c() // This always sugars to `dynamicallyCall(withArguments: [])`.
// Never sugars to `dynamicallyCall()` (using default arguments).

We could change @dynamicCallable to rewrite dynamic calls with no arguments into default argument calls, but that's quite irregular. Disabling default arguments makes more sense to me.

The "tuple_expr element type mismatch" error happens during AST verification.
Namely, a tuple argument has type Struct, not Proto as expected.

I dumped the AST of the code with the direct call (i.e. a.dynamicallyCall(withArguments: [a.dynamicallyCall(withKeywordArguments: ["": a, "key": a])])), and found uses of ErasureExpr:

$ swiftc -dump-ast dc.swift
... // whole bunch of stuff
(erasure_expr implicit type='Proto' location=dc.swift:29:92 range=[dc.swift:29:92 - line:29:92]
    (normal_conformance type=Struct protocol=Proto)
    (declref_expr type='Struct' location=dc.swift:29:92 range=[dc.swift:29:92 - line:29:92] decl=dc.(file).crasher().a@dc.swift:25:7 function_ref=unapplied)))

In CSApply.cpp, perhaps generating ErasureExpr in situations like this is necessary. (Though, really we'd like TC.typeCheckExpression to perform erasure and resolve the correct type for us.)

Comment by Parker Schuh (JIRA)

This has been fixed in the tensorflow branch.