Add AST representation for coroutines by asl · Pull Request #85372 · swiftlang/swift

asl · 2025-11-06T22:38:05Z

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 · 2025-11-06T22:40:19Z

@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 · 2025-11-06T23:42:03Z

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

asl · 2025-11-13T07:02:13Z

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

asl · 2025-11-13T20:34:42Z

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

asl · 2025-11-14T08:02:00Z

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

asl · 2026-01-05T22:15:42Z

swiftlang/swift-syntax#3225
@swift-ci please test

asl · 2026-01-05T22:25:12Z

@slavapestov @rjmccall

The updated PR contains the support for yields w/o dedicated yield result type (I added them on top of the previous attempts to show the approach).

Things to note:

There are no silgen changes here (as we discussed), though I have ported them separately and verified that removing special path for coroutine accessors and treating them as "ordinary coroutines" does not lead to any test breakage
Function types support multiple yields (there was some initial boilerplate for this there), but I decided to postpone decision how we'd represent multiple yields for declarations (similar to error types), so declarations only support a single yield for now.
It turned out that swift syntax parser treats function result arrow as a part of result clause, so to minimize amount of changes I decided to use for yields the syntax similar to the throws, so the yielded type uses contextual yields keyword that (if present) should be after after specifiers like throws or async
Function type construction always requires yield types to be passed (even if empty), so they won't forgotten by accident. Though, the default implementation w/o yields could be added (I left it commented out for now)
Everything is hidden behind dedicated experimental flag

Please let me know if there is something that should be changed / done differently in this approach.

asl · 2026-01-05T22:38:01Z

swiftlang/swift-syntax#3225
@swift-ci please test

asl · 2026-01-06T08:19:41Z

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

asl · 2026-01-06T20:28:52Z

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

asl · 2026-01-07T19:23:05Z

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

asl · 2026-01-08T06:14:00Z

Looks like main is broken:

[2026-01-08T05:03:21.576Z] /Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-main/swift/stdlib/public/core/StaticPrint.swift:866:29: error: expression uses unsafe constructs but is not marked with 'unsafe' [#]8;;https://docs.swift.org/compiler/documentation/diagnostics/strict-memory-safety\StrictMemorySafety]8;;\]
[2026-01-08T05:03:21.576Z] 864 |   let argumentClosures = message.interpolation.arguments.argumentClosures
[2026-01-08T05:03:21.576Z] 865 |   if Bool(_builtinBooleanLiteral: Builtin.ifdef_SWIFT_STDLIB_PRINT_DISABLED()) { return }
[2026-01-08T05:03:21.576Z] 866 |   let formatStringPointer = _getGlobalStringTablePointer(formatString)
[2026-01-08T05:03:21.576Z]     |                             |- error: expression uses unsafe constructs but is not marked with 'unsafe' [#]8;;https://docs.swift.org/compiler/documentation/diagnostics/strict-memory-safety\StrictMemorySafety]8;;\]
[2026-01-08T05:03:21.576Z]     |                             `- note: reference to global function '_getGlobalStringTablePointer' involves unsafe type 'UnsafePointer<CChar>' (aka 'UnsafePointer<Int8>')
[2026-01-08T05:03:21.576Z] 867 |   unsafe constant_vprintf_backend(
[2026-01-08T05:03:21.576Z] 868 |     fmt: formatStringPointer,
[2026-01-08T05:03:21.576Z] 
[2026-01-08T05:03:21.576Z] [#StrictMemorySafety]: <https://docs.swift.org/compiler/documentation/diagnostics/strict-memory-safety>
[2026-01-08T05:03:21.576Z] ninja: build stopped: subcommand failed.
[2026-01-08T05:03:21.576Z] ERROR: command `['env', '/usr/local/bin/cmake', '--build', '/Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-main/build/buildbot_incremental/minimalstdlib-macosx-x86_64', '--config',

asl · 2026-01-08T06:14:09Z

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

rjmccall

I think just worrying about the AST part of this is fine for now, yeah. This seems like good progress.

rjmccall · 2026-01-13T00:00:35Z

include/swift/ABI/MetadataValues.h

+    HasSendingResult       = 0x00000010U,
+
+    // Values if we have any yields
+    IsCoroutine            = 0x00000020U,


Do you really need runtime metadata support? I don't think there's anything wrong with the code you're adding here, but I don't know if I'm happy about baking ABI support into the runtime for a feature we haven't actually added to the language.

Here (and many other places), I would like to avoid baking in that "coroutine" means this specific kind of coroutine. We do have other coroutine-like features, and I think we will probably add more. "YieldOnceCoroutine" is unambiguous.

So, just to clarify – in other places you'd also want to have, say FunctionType::isYieldOnceCoroutine()? This looks different from e.g. SIL level when SILFunctionType::isCoroutine() means any coroutine (being it yield_once or yield_many).

That's true. On the other hand, on SILFunctionType we do actually store a coroutine kind, and the calls to isCoroutine() really are all asking for any kind of coroutine. Maybe we just don't need to model that for AST coroutine kinds, though.

rjmccall · 2026-01-13T00:07:35Z

include/swift/AST/Types.h


 public:
  /// 'Constructor' Factory Function
+#if 0  


Refactor residue?

Oh, no. As I mentioned, I have not decided whether to keep or not yield-less ctors. As one one hand they are less verbose, but on other hand make it easy to forget about yields leading to subtle unintended differences

Yeah, it's tricky. I wonder if we can make most of the synthesis call sites call some subsystem-specific helper function instead of directly calling the main constructor. If we did that refactor, we'd be a lot freer to make these generalizations without worrying about making it absolutely awful to write and maintain AST synthesis code.

rjmccall · 2026-01-13T00:08:01Z

include/swift/AST/Types.h

 }

-  CanFunctionType substGenericArgs(SubstitutionMap subs) const;
+#if 0


lib/AST/ASTMangler.cpp

rjmccall · 2026-01-13T00:14:54Z

lib/AST/ASTVerifier.cpp

        Out << "\n";
        abort();
      }
+      if (FT->hasExtInfo() && FT->isCoroutine()) {


Suggested change

if (FT->hasExtInfo() && FT->isCoroutine()) {

if (FT->isCoroutine()) {

rjmccall · 2026-01-13T00:16:43Z

lib/AST/Builtins.cpp

          _label("operation",
                 _sending(_function(_async(_throws(_thick)), _typeparam(0),
-                                    _parameters())))),
+                                    _parameters(), _yields())))),


We should be able to figure out a way to not need a builder for the yields when we don't have any.

rjmccall · 2026-01-13T00:18:37Z

lib/AST/Builtins.cpp

      FunctionType::ExtInfo info;
      auto innerFunction =
-          FunctionType::get(params, linearFnResultGen.build(builder), info);
+          FunctionType::get(params, {}, linearFnResultGen.build(builder), info);


It's unfortunate that we need this change in a million places. It was probably really nice for writing this patch that you had to fix a bunch of generic places to propagate and handle yields, but now that that's done, I wonder if we shouldn't just have a factory that defaults to not having any yields.

That's exactly what I mentioned above. I do not know :) I'm worrying that the caller might forget about yields and it might lead to dropping yields should they present during various things here and there

I was also thinking to have, say FunctionType::getWithoutYields that would just pass empty yields, however, it looks like as verbose as just passing empty array ref...

…ype checks

…unction types and declarations

asl · 2026-01-15T05:57:44Z

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

asl · 2026-01-16T07:15:18Z

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

rjmccall · 2026-01-20T21:01:02Z

Hi, Anton. I'll try to get back to this in a week; I've been getting over a case of the flu and needing to budget my energy.

asl mentioned this pull request Nov 6, 2025

Add AST representation for coroutines #78508

Draft

asl force-pushed the coro-ast-no-diff branch from 8805213 to 29ab221 Compare November 13, 2025 07:01

asl force-pushed the coro-ast-no-diff branch from 29ab221 to 28dadc4 Compare November 13, 2025 20:34

asl requested a review from rjmccall January 5, 2026 22:25

asl force-pushed the coro-ast-no-diff branch from d5b8b73 to e336b6a Compare January 5, 2026 22:37

asl mentioned this pull request Jan 6, 2026

Changes to LLDB swift type system plugin due to introduction of coroutines to AST swiftlang/llvm-project#12064

Open

asl force-pushed the coro-ast-no-diff branch from e336b6a to 1c28062 Compare January 6, 2026 20:28

rjmccall reviewed Jan 13, 2026

View reviewed changes

asl added 12 commits January 13, 2026 16:33

Add basic boilerplate for AST coroutines and yields

6a58a34

First cut of making coroutine AST type

ae7857f

Add parsing of @yield_once and @yields attributes and corresponding t…

5e5f5a2

…ype checks

Properly substitute coroutines

5f1bec2

Few fixes related to coroutine function types.

6dfc5a3

Unbreak tests after read / modify accessors added

1ec0e44

Add typecheck tests for @yield_once / @yields

b338da9

Remove YieldResult type, switch to direct yields representation for f…

cc43088

…unction types and declarations

Deconstruct Escapable check for coroutines with normal results

9717ab8

Hide non-accessor coroutines behind experimental flag

ac5416d

Fix serialization / deserialization of non-accessor coroutines

6e454b2

Properly mangle yields

4cdca9e

asl force-pushed the coro-ast-no-diff branch from 1c28062 to 4cdca9e Compare January 14, 2026 20:51

asl requested a review from rjmccall January 19, 2026 19:36

	if (FT->hasExtInfo() && FT->isCoroutine()) {
	if (FT->isCoroutine()) {

Conversation

asl commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

asl commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

asl commented Nov 6, 2025

Uh oh!

asl commented Nov 13, 2025

Uh oh!

asl commented Nov 13, 2025

Uh oh!

asl commented Nov 14, 2025

Uh oh!

asl commented Jan 5, 2026

Uh oh!

asl commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

asl commented Jan 5, 2026

Uh oh!

asl commented Jan 6, 2026

Uh oh!

asl commented Jan 6, 2026

Uh oh!

asl commented Jan 7, 2026

Uh oh!

asl commented Jan 8, 2026

Uh oh!

asl commented Jan 8, 2026

Uh oh!

rjmccall left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rjmccall Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asl commented Jan 15, 2026

Uh oh!

asl commented Jan 16, 2026

Uh oh!

rjmccall commented Jan 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

asl commented Nov 6, 2025 •

edited

Loading

asl commented Nov 6, 2025 •

edited

Loading

asl commented Jan 5, 2026 •

edited

Loading

rjmccall Jan 28, 2026 •

edited

Loading