Add AST representation for coroutines

[asl]

This is a proof-of-concept PR adding AST representation for coroutines

Further background at https://forums.swift.org/t/pitch-yield-once-functions-first-class-coroutines/77081

[asl]

@tkremenek @rjmccall Following discussions on LLVM Dev Meeting, this is a stripped-down version of #78508:

• No autodiff-related parts
• No silgen (besides the "standard" special path used for coroutine accessors)
• Some other fixes for SIL optimizer is omitted

Essentially the PR contains AST-related bits for coroutine declarations and coroutine function types as well as required boilerplate for AST mangling, dumping, serialization, etc.

@xedin comments from the original PR were addressed as well.

[asl]

Please test with following pull request: swiftlang/llvm-project#11396
@swift-ci please test

[asl]

Please test with following pull request: swiftlang/llvm-project#11396
@swift-ci please test

[asl]

Please test with following pull request: swiftlang/llvm-project#11396
@swift-ci please test

[asl]

Please test with following pull request: swiftlang/llvm-project#11396
@swift-ci please test windows platform

[asl]

swiftlang/swift-syntax#3225 swiftlang/llvm-project#12064
@swift-ci please test

[asl]

@rjmccall ping

[asl]

swiftlang/swift-syntax#3225 swiftlang/llvm-project#12064
@swift-ci please test

[asl]

@rjmccall Ping. Will you please check it out?

[rjmccall]

Sorry for letting this slip. I'm confused about the structure of yields that we're modeling here, because we seem to allow a list of (ownership, type) pairs in some places but only a single type in others.

[asl]

Sorry for letting this slip. I'm confused about the structure of yields that we're modeling here, because we seem to allow a list of (ownership, type) pairs in some places but only a single type in others.

This is a good question :) And I'd suppose this is the similar to what @slavapestov asked about thrown error types: should we allow multiple thrown error types? Or tuple with types, etc.

At SIL level we can have multiple yields each could be direct and indirect. AnyFunctionType::Yield is pre-existing (though it was essentially unused) and from that I deduced that you wanted to support multiple yields when you added it.

Currently declarations only support a single yield type (similar to thrown error type) and it could only be optionally inout, but function types potentially support multiple yields with all possible value ownerships, however, I put couple of asserts to ensure we only proceed with the single yield type.

I can potentially support multiple yield types on declarations and all different value ownership, if you think it would make sense.

[rjmccall]

Error types are different — listing multiple error types is really just saying that the error could be any of the given types. With yields, yeah, I think it's more like a parameter list in the sense that it makes sense to be able to yield multiple independent values at once. Even if accessors don't need it, I think it's consistent to just go ahead and use a type that allows that to be modeled directly. Plus that way you can just have a YieldList type that includes the keyword location instead of passing that around separately.

The grammar you're using already delimits the yields, like yields(Int), right? So there's no ambiguity between a tuple and a list of separate yields.

[asl]

The grammar you're using already delimits the yields, like yields(Int), right? So there's no ambiguity between a tuple and a list of separate yields.

Right, there is no ambiguity here. Looks like then we will need to extend yield here as well, so it will be able to yield multiple values. Looks like again closing gap between source language and SIL as SIL yield could yield multiple values.

I will extend the declarations then, looks straightforward.

[asl]

swiftlang/swift-syntax#3225 swiftlang/llvm-project#12064
@swift-ci please test

[asl]

@rjmccall This new version allows for multiple yields on declarations as well. Will you please take a look?

[asl]

swiftlang/swift-syntax#3225 swiftlang/llvm-project#12064
@swift-ci please test