SE-0492: Metatypes and existential metatypes #85139

kubamracek · 2025-10-26T05:04:14Z

SE-0492 declared that constant expressions should support metatypes (of non-generic, non-resilient types). This adds support for using metatypes (T.self) and existential metatypes (upcasts to Any.Type, etc.) as static initializers for global variables, including those with @section attributes.

Major parts:

OptUtils.swift now allows MetatypeInst and InitExistentialMetatypeInst as valid static initializers for non-generic, non-resilient types.
IRGen now constant folds MetatypeInst and InitExistentialMetatypeInst
LegalConstExprVerifier now allows metatype erasure expressions

DougGregor

This approach looks reasonable to me. I do really like having this feature, but it's a reasonable basis for any kind of "type registry" in the language

SwiftCompilerSources/Sources/Optimizer/Utilities/OptUtils.swift

eeckstein · 2025-11-03T18:28:40Z

test/ConstValues/SectionIR.swift

+@section("mysection") let metatype2: Any.Type = Int.self
+@section("mysection") let metatype3: Any.Type = S.self
+@section("mysection") let metatype4: any (Hashable & Sendable).Type = Int.self
+@section("mysection") let metatype5: any (Hashable & Sendable).Type = S.self


Can you add tests for bound generic types, e.g. Array<Int>.self?

We're rejecting that case syntactically: https://github.com/swiftlang/swift/pull/85139/files#diff-ea7de05f211d676ea604c35f0e6b253fb4a454efbfcc84928a931bab113e7bdcR82

...but I did add that as a SIL test into test/SILOptimizer/static_init_metatypes.swift.

kubamracek · 2025-11-04T19:27:33Z

@swift-ci please test

kubamracek · 2025-11-04T20:56:30Z

And to point out explicitly: The OptUtils.swift and IRGen changes now cause MetatypeInst and InitExistentialMetatypeInst to be constant folded and statically initialized even outside of @section-annotated globals. Is that reasonable, @eeckstein ?

eeckstein · 2025-11-05T08:38:33Z

test/SILOptimizer/static_init_metatypes.swift

@@ -0,0 +1,57 @@
+// RUN: %target-swift-frontend %s -parse-as-library -module-name=test -emit-sil | %FileCheck %s
+// RUN: %target-swift-frontend %s -parse-as-library -O -module-name=test -emit-sil | %FileCheck %s


Please also add a -emit-ir invocation to make sure that IRGen can deal with this.

Is that reasonable

Yes, that should be fine. As long as IRGen can handle those SIL initializer instructions.

Added the -emit-ir checks

kubamracek · 2025-11-05T14:02:13Z

https://ci.swift.org/job/swift-PR-macos/25548/console

[2025-11-04T22:52:04.921Z]   Swift(macosx-x86_64) :: Macros/macro_expand_extensions.swift

[2025-11-04T22:21:00.600Z] Undefined symbols for architecture x86_64:
[2025-11-04T22:21:00.600Z]   "_$s9MacroUser16TestAvailabilityVSQAAWP", referenced from:
[2025-11-04T22:21:00.600Z]       _$s9MacroUser16TestAvailabilityV1xSQ_pXpvpZ in macro_expand_extensions-787e4c.o

https://ci.swift.org/job/swift-PR-Linux/24711/console

12:43:31    Swift(linux-x86_64) :: Macros/macro_expand_extensions.swift

[2025-11-04T20:35:31.651Z] /tmp/lit-tmp-39x03tfx/macro_expand_extensions-e4e00b.o:macro_expand_extensions-e4e00b.o:$s9MacroUser16TestAvailabilityV1xSQ_pXpvpZ: error: undefined reference to '$s9MacroUser16TestAvailabilityVSQAAWP'

https://ci-external.swift.org/job/swift-PR-windows/47464/console

   Creating library lib\SWBProtocol.lib and object lib\SWBProtocol.exp
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol21AppleScriptBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol19CopyFilesBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol20FrameworksBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol17HeadersBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol21JavaArchiveBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol19ResourcesBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol13RezBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP
BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol21ShellScriptBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP

BuildPhase.swift.obj : error LNK2001: unresolved external symbol $s11SWBProtocol17SourcesBuildPhaseC7SWBUtil23PolymorphicSerializableAAWP

bin\SWBProtocol.dll : fatal error LNK1120: 9 unresolved externals

I think those are all real issues caused by the new constant folding actually adding these referencing to the witness tables. @eeckstein any ideas here?

eeckstein · 2025-11-05T15:37:07Z

Difficult to say without looking at the generated llvm ir. Maybe it's a problem if the referenced type is defined in a different module

kubamracek · 2025-11-10T22:59:31Z

Hm so this is related to conformances being considered "resilient" separately from the type being resilient: https://github.com/swiftlang/swift/blob/main/lib/IRGen/GenProto.cpp#L990

I think this means that we should not and cannot constant fold any conformances to the common Hashable, Equatable, etc. protocols, and only allow constant folding when the protocol is defined in the same module as the type (basically mirror the rules of https://github.com/swiftlang/swift/blob/main/lib/IRGen/GenProto.cpp#L990).

@eeckstein does that sound right?

@DougGregor I think this also somewhat restricts the usability of @section for runtime type registration/discovery -- for example we can't have one library provide a (stable/resilient) PluginProtocol and have separately compiled clients publish their conformances to it in @section-placed globals... Thoughts?

eeckstein · 2025-11-11T19:02:25Z

Yeah, I think this is right.

If metatype needs runtime instantiation, as a workaround one could add functions/closures in a section which return the metatype, e.g.

@section S
let metatypeGetter: () -> P.Type = { X.self }

kubamracek · 2025-11-11T23:23:18Z

@swift-ci please test

kubamracek · 2025-11-12T00:47:47Z

@swift-ci please test

kubamracek · 2025-11-12T18:54:36Z

@swift-ci please test

kubamracek · 2025-11-12T18:59:39Z

@swift-ci please test

kubamracek · 2025-11-12T22:11:07Z

@swift-ci please test

kubamracek · 2025-11-14T22:44:49Z

@swift-ci please test

….swift

…stead of isGeneric()

…lasses

kubamracek · 2025-11-15T18:19:38Z

@swift-ci please test

kubamracek · 2025-11-16T05:23:18Z

swiftlang/swift-foundation#1602

@swift-ci please test Linux platform

kubamracek · 2025-11-16T05:23:31Z

swiftlang/swift-docc#1351

@swift-ci please test Windows platform

kubamracek · 2025-11-16T16:38:10Z

swiftlang/swift-docc#1351

@swift-ci please smoke test Windows

kubamracek · 2025-11-16T17:42:00Z

swiftlang/swift-foundation#1602

@swift-ci please test Linux platform

kubamracek requested a review from DougGregor October 26, 2025 05:04

DougGregor approved these changes Oct 31, 2025

View reviewed changes

eeckstein reviewed Nov 3, 2025

View reviewed changes

kubamracek force-pushed the section-metatypes branch from a27abcc to 16ebf84 Compare November 4, 2025 19:14

kubamracek changed the title ~~[WIP] SE-0492: Metatypes and existential metatypes~~ SE-0492: Metatypes and existential metatypes Nov 4, 2025

kubamracek marked this pull request as ready for review November 4, 2025 19:18

kubamracek requested review from hborla, jckarter, rjmccall, slavapestov and xedin as code owners November 4, 2025 19:18

eeckstein reviewed Nov 5, 2025

View reviewed changes

kubamracek force-pushed the section-metatypes branch 3 times, most recently from 1caa69b to 3376a9b Compare November 11, 2025 22:25

kubamracek force-pushed the section-metatypes branch from 65e9122 to 31e114b Compare November 14, 2025 22:44

kubamracek added 2 commits November 15, 2025 10:18

SE-0492: Metatypes and existential metatypes

e62330a

Restrict metatype support in @section to only non-resilient conformances

40ade98

kubamracek added 6 commits November 15, 2025 10:18

Fold optimizable_metatype_references.swift into static_init_metatypes…

6827f2c

….swift

Fix build of LegalConstExprVerifier.cpp: Use hasGenericParamList() in…

d0e0e90

…stead of isGeneric()

Fix generic detection, assert we have addressable metadata, expand tests

410fdd1

Minimize ASTBridging.h / ASTBridgingImpl.h #includes

99667db

Further restrict MetatypeInst constant folding to not constant fold c…

9cd56b1

…lasses

Don't constant fold metatypes that indirectly contain resilient types

75f6a28

kubamracek force-pushed the section-metatypes branch from 31e114b to 75f6a28 Compare November 15, 2025 18:19

		@@ -0,0 +1,57 @@
		// RUN: %target-swift-frontend %s -parse-as-library -module-name=test -emit-sil \| %FileCheck %s
		// RUN: %target-swift-frontend %s -parse-as-library -O -module-name=test -emit-sil \| %FileCheck %s

SE-0492: Metatypes and existential metatypes #85139

Are you sure you want to change the base?

SE-0492: Metatypes and existential metatypes #85139

Conversation

kubamracek commented Oct 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DougGregor left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

eeckstein Nov 3, 2025

Choose a reason for hiding this comment

Uh oh!

kubamracek Nov 3, 2025

Choose a reason for hiding this comment

Uh oh!

kubamracek Nov 4, 2025

Choose a reason for hiding this comment

Uh oh!

kubamracek commented Nov 4, 2025

Uh oh!

kubamracek commented Nov 4, 2025

Uh oh!

eeckstein Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

eeckstein Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

kubamracek Nov 11, 2025

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

eeckstein commented Nov 5, 2025

Uh oh!

kubamracek commented Nov 10, 2025

Uh oh!

eeckstein commented Nov 11, 2025

Uh oh!

kubamracek commented Nov 11, 2025

Uh oh!

kubamracek commented Nov 12, 2025

Uh oh!

kubamracek commented Nov 12, 2025

Uh oh!

kubamracek commented Nov 12, 2025

Uh oh!

kubamracek commented Nov 12, 2025

Uh oh!

kubamracek commented Nov 14, 2025

Uh oh!

kubamracek commented Nov 15, 2025

Uh oh!

kubamracek commented Nov 16, 2025

Uh oh!

kubamracek commented Nov 16, 2025

Uh oh!

kubamracek commented Nov 16, 2025

Uh oh!

kubamracek commented Nov 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kubamracek commented Oct 26, 2025 •

edited

Loading

kubamracek commented Nov 5, 2025 •

edited

Loading