Bridging: Implement bridges required for ongoing AutoDiff changes #84648

kovdan01 · 2025-10-02T14:47:05Z

In #83926, part of the changes resolving #68944 is submitted. The AutoDiff closure specialization optimizer pass relies on several AST-level bridges not implemented yet.

This patch introduces these missing bridges. See the list of the changes below.

TODO: Update description when the final set of bridges is establishes after review

AST:

Define .asValueDecl on each BridgedXXXDecl type that's also a ValueDecl.
Define .asNominalTypeDecl on each BridgedXXXDecl type that's also a NominalTypeDecl.
Define .asGenericContext on each BridgedXXXDecl type that's also a GenericContext.
class BridgedSourceFile:
- Make nullable
- func addTopLevelDecl(_ decl: BridgedDecl)
class BridgedFileUnit:
- func castToSourceFile() -> BridgedNullableSourceFile
class BridgedDecl:
- func getDeclContext() -> BridgedDeclContext
class BridgedParamDecl:
- func cloneWithoutType() -> BridgedParamDecl
- func setInterfaceType(_ type : BridgedASTType)
Define BridgedDecl.setImplicit() instead of BridgedParamDecl.setImplicit()
class BridgedGenericContext:
- setGenericSignature(_ genSig: BridgedGenericSignature)
Change return type of BridgedEnumDecl.createParsed(/*...*/) from BridgedNominalTypeDecl to BridgedEnumDecl
class BridgedValueDecl:
- func setAccess(_ accessLevel: swift.AccessLevel)
class BridgedNominalTypeDecl:
- func addMember(_ member: BridgedDecl)
class BridgedGenericTypeParamDecl:
- func createImplicit(declContext: BridgedDeclContext, name: swift.Identifier, depth: UInt, index: UInt, paramKind: swift.GenericTypeParamKind)
class ValueDecl:
- var baseIdentifier: swift.Identifier
class NominalTypeDecl:
- var declaredInterfaceType: Type
class EnumElementDecl:
- var parameterList: BridgedParameterList
- var nameStr: StringRef
struct GenericSignature:
- var canonicalSignature: CanGenericSignature
struct CanGenericSignature:
- var isEmpty: Bool
- var genericSignature: GenericSignature
struct Type:
- func mapTypeOutOfContext() -> Type
- func getReducedType(sig: GenericSignature) -> CanonicalType
- func GenericTypeParam_getName() -> swift.Identifier
- func GenericTypeParam_getDepth() -> UInt
- func GenericTypeParam_getIndex() -> UInt
- func GenericTypeParam_getParamKind() -> swift.GenericTypeParamKind
struct CanonicalType:
- func SILFunctionType_getSubstGenericSignature() -> CanGenericSignature
- func loweredType(in function: SIL.Function) -> SIL.Type

SIL:

class Argument:
- func replaceAllUsesWith(newArg: Argument)
class BasicBlock:
- func insertPhiArgument(atPosition: Int, type: Type, ownership: Ownership, _ context: some MutatingContext) -> Argument
struct Builder:
- func createTuple(elements: [Value]) -> TupleInst
protocol Context:
- func getTupleType(elements: [AST.Type]) -> AST.Type
- func getTupleTypeWithLabels(elements: [AST.Type], labels: [swift.Identifier]) -> AST.Type
class Function:
- var sourceFile: BridgedNullableSourceFile
- func mapTypeIntoContext(_ type: Type) -> Type
class PartialApplyInst:
- var substitutionMap: SubstitutionMap
class SwitchEnumInst:
- var numCases: Int
- public func getSuccessorForDefault() -> BasicBlock?
Type:
- var category: ValueCategory
- func getEnumCasePayload(caseIdx: Int, function: Function) -> Type
- func mapTypeOutOfContext() -> Type
- static func getPrimitiveType(canType: CanonicalType, silValueCategory: ValueCategory) -> Type
struct EnumCase:
- let enumElementDecl: EnumElementDecl
struct TupleElementArray:
- func label(at index: Int) -> swift.Identifier
Define enum ValueCategory with address and object elements

kovdan01 · 2025-10-02T14:49:54Z

Tagging @JaapWijnen

asl · 2025-10-02T15:30:57Z

@kovdan01 Will you please summarize the list of changes in the PR description? Overall, while these are prerequisites for autodiff-related closure specialization pass, overall these bridges are not autodiff-specific.

In #83926, part of the changes resolving #68944 is submitted. The AutoDiff closure specialization optimizer pass relies on several bridges not implemented yet. This patch introduces these missing bridges. See the list of the changes below. **AST:** * Define `.asValueDecl` on each BridgedXXXDecl type that's also a ValueDecl. * Define `.asNominalTypeDecl` on each BridgedXXXDecl type that's also a NominalTypeDecl. * Define `.asGenericContext` on each BridgedXXXDecl type that's also a GenericContext. * `class BridgedSourceFile`: - Make nullable - `func addTopLevelDecl(_ decl: BridgedDecl)` * `class BridgedFileUnit`: - `func castToSourceFile() -> BridgedNullableSourceFile` * `class BridgedDecl`: - `func getDeclContext() -> BridgedDeclContext` * `class BridgedParamDecl`: - `func cloneWithoutType() -> BridgedParamDecl` - `func setInterfaceType(_ type : BridgedASTType)` * Define `BridgedDecl.setImplicit()` instead of `BridgedParamDecl.setImplicit()` * `class BridgedGenericContext`: - `setGenericSignature(_ genSig: BridgedGenericSignature)` * Change return type of `BridgedEnumDecl.createParsed(/*...*/)` from `BridgedNominalTypeDecl` to `BridgedEnumDecl` * `class BridgedValueDecl`: - `func setAccess(_ accessLevel: swift.AccessLevel)` * `class BridgedNominalTypeDecl`: - `func addMember(_ member: BridgedDecl)` * `class BridgedGenericTypeParamDecl`: - `func createImplicit(declContext: BridgedDeclContext, name: swift.Identifier, depth: UInt, index: UInt, paramKind: swift.GenericTypeParamKind)` * `class ValueDecl`: - `var baseIdentifier: swift.Identifier` * `class NominalTypeDecl`: - `var declaredInterfaceType: Type` * `class EnumElementDecl`: - `var parameterList: BridgedParameterList` - `var nameStr: StringRef` * `struct GenericSignature`: - `var canonicalSignature: CanGenericSignature` * `struct CanGenericSignature`: - `var isEmpty: Bool` - `var genericSignature: GenericSignature` * `struct Type`: - `func mapTypeOutOfContext() -> Type` - `func getReducedType(sig: GenericSignature) -> CanonicalType` - `func GenericTypeParam_getName() -> swift.Identifier` - `func GenericTypeParam_getDepth() -> UInt` - `func GenericTypeParam_getIndex() -> UInt` - `func GenericTypeParam_getParamKind() -> swift.GenericTypeParamKind` * `struct CanonicalType`: - `func SILFunctionType_getSubstGenericSignature() -> CanGenericSignature` - `func loweredType(in function: SIL.Function) -> SIL.Type` **SIL:** * `class Argument`: - `func replaceAllUsesWith(newArg: Argument)` * `class BasicBlock`: - `func insertPhiArgument(atPosition: Int, type: Type, ownership: Ownership, _ context: some MutatingContext) -> Argument` * `struct Builder`: - `func createTuple(elements: [Value]) -> TupleInst` * `protocol Context`: - `func getTupleType(elements: [AST.Type]) -> AST.Type` - `func getTupleTypeWithLabels(elements: [AST.Type], labels: [swift.Identifier]) -> AST.Type` * `class Function`: - `var sourceFile: BridgedNullableSourceFile` - `func mapTypeIntoContext(_ type: Type) -> Type` * `class PartialApplyInst`: - `var substitutionMap: SubstitutionMap` * `class SwitchEnumInst`: - `var numCases: Int` - `public func getSuccessorForDefault() -> BasicBlock?` * `Type`: - `var category: ValueCategory` - `func getEnumCasePayload(caseIdx: Int, function: Function) -> Type` - `func mapTypeOutOfContext() -> Type` - `static func getPrimitiveType(canType: CanonicalType, silValueCategory: ValueCategory) -> Type` * `struct EnumCase`: - `let enumElementDecl: EnumElementDecl` * `struct TupleElementArray`: - `func label(at index: Int) -> swift.Identifier` * Define `enum ValueCategory` with `address` and `object` elements

kovdan01 · 2025-10-06T14:58:59Z

@kovdan01 Will you please summarize the list of changes in the PR description? Overall, while these are prerequisites for autodiff-related closure specialization pass, overall these bridges are not autodiff-specific.

@asl Thanks for suggestion, updated the comment

kovdan01 · 2025-10-06T15:09:59Z

@swift-ci please test

eeckstein · 2025-10-06T16:22:58Z

@kovdan01 I'll review this tomorrow

SwiftCompilerSources/Sources/AST/Declarations.swift

eeckstein · 2025-10-07T08:19:52Z

SwiftCompilerSources/Sources/AST/Declarations.swift


 final public class EnumElementDecl: ValueDecl {
  public var hasAssociatedValues: Bool { bridged.EnumElementDecl_hasAssociatedValues() }
+  public var parameterList: BridgedParameterList { bridged.EnumElementDecl_getParameterList() }


Please don't expose bridged data structures in APIs. Create a native swift ParameterList containing a var bridged: BridgedParameterList

I've defined a public typealias ParameterList = BridgedParameterList. Is this considered OK or it's required to create a native swift ParameterList containing a var bridged: BridgedParameterList?

It depends if you need APIs for ParameterList. E.g. if you want to access the elements, it makes sense to add a native ParameterList, conforming to Sequence, etc.

SwiftCompilerSources/Sources/AST/Declarations.swift

SwiftCompilerSources/Sources/AST/GenericSignature.swift

lib/AST/Bridging/DeclBridging.cpp

eeckstein · 2025-10-07T09:32:12Z

lib/AST/Bridging/GenericsBridging.cpp

  return decl;
 }

+BridgedGenericTypeParamDecl BridgedGenericTypeParamDecl_createImplicit(


This is needed to mimic behavior of cloneGenericParameters - see

swift/lib/SILOptimizer/Differentiation/LinearMapInfo.cpp

Lines 36 to 50 in d388da7

/// Clone the generic parameters of the given generic signature and return a new

/// `GenericParamList`.

static GenericParamList *cloneGenericParameters(ASTContext &ctx,

DeclContext *dc,

CanGenericSignature sig) {

SmallVector<GenericTypeParamDecl *, 2> clonedParams;

for (auto paramType : sig.getGenericParams()) {

auto *clonedParam = GenericTypeParamDecl::createImplicit(

dc, paramType->getName(), paramType->getDepth(), paramType->getIndex(),

paramType->getParamKind());

clonedParam->setDeclContext(dc);

clonedParams.push_back(clonedParam);

}

return GenericParamList::create(ctx, SourceLoc(), clonedParams, SourceLoc());

}

include/swift/AST/ASTBridging.h

…ure-spec

kovdan01

@eeckstein Thanks for a detailed review! I've tried to address all the feedback.

I've resolved the threads which seem trivial enough to avoid cluttering the PR (feel free to unresolve if things do not look fixed from your point of view).
Remaining unresolved threads contain some questions on implementation details - would be glad to continue discussion and finish corresponding fixes after additional clarification.

And here is one more big overall comment on this PR.

I've introduced a bunch of new public typealiases for bridged types which need to be exposed to the AutoDiff closure specialization pass in order to resolve #68944 (to avoid exposing bridges directly as requested in feedback).

Unfortunately, we have a conflict of two different approaches to implementing AST-level bridges.

On the one hand, we have BridgedDeclObj which is accessible via bridged member of Decl class - see SwiftCompilerSources/Sources/AST/Declarations.swift. We have a bunch of Swift classes derived from that, and BridgedDeclObj contains methods which we call from all such derived classes.
On the other hand, we have automatically generated BridgedXXX bridges, where XXX is a name of C++ type: BridgedDecl, BridgedASTContext, BridgedParameterList, etc. Swift is not aware of how these are derived from each other, instead, we have asXXX fields defined where needed, like asDecl, asNominalTypeDecl, etc. These allow derived objects to call methods of bases objects even though Swift is not aware of inheritance structure. For example: newED.asNominalTypeDecl.addMember(newEED.asDecl), where newED and newEED are instances of BridgedEnumDecl and BridgedEnumElementDecl correspondingly.

Bridges from p.2 are primarily used in ASTGen (see lib/ASTGen). We need them for AutoDiff closure specialization pass since we need to create a new specialized branch tracing enum decl. In other words, we literally need to generate AST, not only look at existing AST :)

A conflict which we hit is name collision for some bridges. For example, we already have EnumDecl and EnumElementDecl classes in Swift, which are derived from Decl (with multiple intermediate classes), while Decl contains bridged: BridgedDeclObj field. We also need to use BridgedEnumDecl and BridgedEnumElementDecl, but we can't just typealias them to EnumDecl and EnumElementDecl because these names are already occupied by existing classes.

Right now, I've just temporarily exposed such bridged names "as is" with Bridged prefix.

Given that, what is the correct way of combining two types of bridges mentioned before? Also, I guess that mixing two types of bridges is not very desirable, but I'm not sure how we can avoid that.

kovdan01 · 2025-10-08T12:43:22Z

SwiftCompilerSources/Sources/SIL/ASTExtensions.swift

    return BoxFieldsArray(boxType: self, function: function)
  }
+
+  public func loweredType(in function: Function) -> Type {


I've introduced a new bridge because existing ones (see C++ implementation below) do not take into account AbstractionPattern constructed with function->getLoweredFunctionType()->getSubstGenericSignature().

See existing bridges:

swift/include/swift/SIL/SILBridgingImpl.h

Lines 911 to 920 in d388da7

BridgedType BridgedFunction::getLoweredType(BridgedASTType type, bool maximallyAbstracted) const {

if (maximallyAbstracted) {

return BridgedType(getFunction()->getLoweredType(swift::Lowering::AbstractionPattern::getOpaque(), type.type));

}

return BridgedType(getFunction()->getLoweredType(type.type));

}

BridgedType BridgedFunction::getLoweredType(BridgedType type) const {

return BridgedType(getFunction()->getLoweredType(type.unbridged()));

}

I implemented a new bridge in order to be able to mimic behavior of getBranchingTraceEnumLoweredType:

swift/include/swift/SILOptimizer/Differentiation/LinearMapInfo.h

Lines 160 to 171 in d388da7

/// Returns the lowered SIL type of the branching trace enum associated with

/// the given original block.

SILType getBranchingTraceEnumLoweredType(SILBasicBlock *origBB) const {

auto *traceDecl = getBranchingTraceDecl(origBB);

auto traceDeclType =

traceDecl->getDeclaredInterfaceType()->getCanonicalType();

Lowering::AbstractionPattern pattern(

derivative->getLoweredFunctionType()->getSubstGenericSignature(),

traceDeclType);

return typeConverter.getLoweredType(pattern, traceDeclType,

TypeExpansionContext::minimal());

}

Should I somehow modify the behavior of existing bridges instead of introducing a new one? E.g. add a new flag with meaning "use this behavior" or smth like that?

SwiftCompilerSources/Sources/AST/Declarations.swift

SwiftCompilerSources/Sources/AST/Type.swift

lib/AST/Bridging/DeclBridging.cpp

kovdan01 · 2025-10-15T16:42:57Z

lib/AST/Bridging/GenericsBridging.cpp

  return decl;
 }

+BridgedGenericTypeParamDecl BridgedGenericTypeParamDecl_createImplicit(


This is needed to mimic behavior of cloneGenericParameters - see

swift/lib/SILOptimizer/Differentiation/LinearMapInfo.cpp

Lines 36 to 50 in d388da7

/// Clone the generic parameters of the given generic signature and return a new

/// `GenericParamList`.

static GenericParamList *cloneGenericParameters(ASTContext &ctx,

DeclContext *dc,

CanGenericSignature sig) {

SmallVector<GenericTypeParamDecl *, 2> clonedParams;

for (auto paramType : sig.getGenericParams()) {

auto *clonedParam = GenericTypeParamDecl::createImplicit(

dc, paramType->getName(), paramType->getDepth(), paramType->getIndex(),

paramType->getParamKind());

clonedParam->setDeclContext(dc);

clonedParams.push_back(clonedParam);

}

return GenericParamList::create(ctx, SourceLoc(), clonedParams, SourceLoc());

}

SwiftCompilerSources/Sources/SIL/Type.swift

eeckstein

Great progress! I'm happy to see all this APIs being made available.

This is my next set of comments

lib/AST/Bridging/DeclBridging.cpp

eeckstein · 2025-10-21T10:39:45Z

include/swift/AST/ASTBridging.h

 #define ABSTRACT_DECL(Id, Parent) DECL(Id, Parent)
 #include "swift/AST/DeclNodes.def"

+// Declare `.asValueDecl` on each BridgedXXXDecl type that's also a


you don't need this (see my other comment)

Deleted .asValueDecl declaration and definition as no longer needed

eeckstein · 2025-10-21T10:49:36Z

include/swift/AST/ASTBridging.h

 #define ABSTRACT_CONTEXT_DECL(Id, Parent) CONTEXT_DECL(Id, Parent)
 #include "swift/AST/DeclNodes.def"

+// Declare `.asGenericContext` on each BridgedXXXDecl type that's also a


Let's model GenericContext correctly in swift:

add a protocol GenericContext: Decl

let all classes which are generic contexts conform to GenericContext

implement all the GenericContext APIs as default methods in a protocol extension (no need to do it for each conforming Decl class)

This is similar to what we do with ApplySite or ForwardingInstruction for SIL instructions.

Created GenericContext protocol, as suggested

eeckstein · 2025-10-21T10:52:01Z

include/swift/AST/ASTBridging.h

 void BridgedDecl_forEachDeclToHoist(BridgedDecl decl,
                                    BridgedSwiftClosure closure);

+SWIFT_NAME("getter:BridgedDecl.declContext(self:)")


The same for DeclContext. Let's make this a protocol in swift

I've introduced DeclContext protocol and made some classes derived from Decl conforming to it (for decls which are also decl contexts). But not only decls might be decl contexts, so I've implemented a fileprivate class DeclContextObj to have a dummy instantiation of DeclContext protocol.

Unfortunately this does not look very nice. Particularly, this is error-prone since one might wrap BridgedDeclContext in DeclContextObj, and trying to access that as Decl would result in nil even if the initial object was indeed a Decl which is also a DeclContext.

What should be the correct way to do this?

that's the right way to do it. Just rename DeclContextObj to UnknownDeclContext.
Alternatively we could bridge all the other DeclContext classes to swift. But some expressions are DeclContexts and bridging the whole expression class hierarchy is out of scope for this PR.

include/swift/SIL/SILBridging.h

SwiftCompilerSources/Sources/AST/Type.swift

eeckstein · 2025-10-21T11:51:24Z

SwiftCompilerSources/Sources/SIL/ASTExtensions.swift

    return BoxFieldsArray(boxType: self, function: function)
  }
+
+  public func loweredType(in function: Function) -> Type {


I see. Please

put this new function next to the existing loweredType in TypeProperties

give it another name which points out the difference

Add a comment explaining the difference, ideally with a small example

eeckstein · 2025-10-21T11:56:52Z

SwiftCompilerSources/Sources/SIL/Function.swift

    return Location(bridged: bridged.getLocation())
  }

+  public var sourceFile: SourceFile? { SourceFile(bridged: bridged.getSourceFile()) }


better:

add var declRef: DeclRef? in Function

add var sourceFile: SourceFile? in DeclRef`

or even better:

add var innermostDeclContext in DeclRef (once you added the protocol DeclContext)

add var sourceFile: SourceFile? in DeclContext`

Adopted the first approach. I would be happy to adopt the second one if it's better, but dealing with DeclContext protocol is a bit painful since we have two types of things which should conform to this: some derivatives Decl (which have native swift classes) and several other entities which do not have native swift classes (so we need to instantiate them as some dummy thing like DeclContextObj - see my other comment)

eeckstein · 2025-10-21T11:59:22Z

SwiftCompilerSources/Sources/SIL/Type.swift

    return EnumCases(enumType: self, function: function)
  }

+  public func getEnumCase(in function: Function, at index: Int) -> EnumCase? {


add this API as a subscript operator on EnumCases.
With a comment warning about O(n) complexity.

Added as subscript operator, thanks

SwiftCompilerSources/Sources/AST/Declarations.swift

…ure-spec

kovdan01

@eeckstein Thanks for a details feedback! I've rebased the PR resolving merge conflicts and addressed the comments. Sometimes I've slightly modified your suggestions - see my replies in corresponding threads.

Also I would be glad to discuss proper DeclContext implementation just in case the current one is not suitable - I personally find it pretty ugly, but I'm not sure how proper implementation should look like keeping inheritance structure of corresponding C++ classes in mind. See my reply corresponding thread.

SwiftCompilerSources/Sources/AST/Declarations.swift

kovdan01 · 2025-11-10T15:55:52Z

SwiftCompilerSources/Sources/AST/Declarations.swift

+
+public typealias FileUnit = BridgedFileUnit
+
+public typealias GenericParamList = BridgedGenericParamList


Introduced native GenericParamList with corresponding bridged field

kovdan01 · 2025-11-10T15:56:28Z

SwiftCompilerSources/Sources/AST/Declarations.swift

+
+public typealias TrailingWhereClause = BridgedTrailingWhereClause
+
+public typealias BridgedParamDecl = ASTBridging.BridgedParamDecl


So, please do not add this public typealiases for bridging classes for which we already have a native Swift type

Deleted such typealiases

kovdan01 · 2025-11-10T15:57:30Z

SwiftCompilerSources/Sources/AST/Declarations.swift

+}
+
+extension BridgedEnumDecl {
+  public static func createParsed(


In order to avoid cluttering BridgedDeclObj with many createXXX methods, I've decided to directly call create static methods of BridgedXXXDecl classes, and then cast results to swift-native XXXDecl classes. Please let me know if this is applicable.

kovdan01 · 2025-11-10T15:57:48Z

SwiftCompilerSources/Sources/SIL/ASTExtensions.swift

    return BoxFieldsArray(boxType: self, function: function)
  }
+
+  public func loweredType(in function: Function) -> Type {


Renamed to loweredTypeWithAbstractionPattern and added a comment.

kovdan01 · 2025-11-10T16:00:52Z

include/swift/AST/ASTBridging.h

 #define ABSTRACT_DECL(Id, Parent) DECL(Id, Parent)
 #include "swift/AST/DeclNodes.def"

+// Declare `.asValueDecl` on each BridgedXXXDecl type that's also a


Deleted .asValueDecl declaration and definition as no longer needed

kovdan01 · 2025-11-10T16:02:58Z

include/swift/AST/ASTBridging.h

 #define ABSTRACT_CONTEXT_DECL(Id, Parent) CONTEXT_DECL(Id, Parent)
 #include "swift/AST/DeclNodes.def"

+// Declare `.asGenericContext` on each BridgedXXXDecl type that's also a


Created GenericContext protocol, as suggested

kovdan01 · 2025-11-10T16:10:08Z

include/swift/AST/ASTBridging.h

 void BridgedDecl_forEachDeclToHoist(BridgedDecl decl,
                                    BridgedSwiftClosure closure);

+SWIFT_NAME("getter:BridgedDecl.declContext(self:)")


I've introduced DeclContext protocol and made some classes derived from Decl conforming to it (for decls which are also decl contexts). But not only decls might be decl contexts, so I've implemented a fileprivate class DeclContextObj to have a dummy instantiation of DeclContext protocol.

Unfortunately this does not look very nice. Particularly, this is error-prone since one might wrap BridgedDeclContext in DeclContextObj, and trying to access that as Decl would result in nil even if the initial object was indeed a Decl which is also a DeclContext.

What should be the correct way to do this?

lib/AST/Bridging/DeclBridging.cpp

SwiftCompilerSources/Sources/AST/Declarations.swift

SwiftCompilerSources/Sources/SIL/Type.swift

SwiftCompilerSources/Sources/AST/Declarations.swift

…ure-spec

kovdan01

@eeckstein Thanks for your feedback! I've submitted updates addressing most of your comments, but I'm still not sure how to properly adopt one of your suggestions. See my reply #84648 (comment).

SwiftCompilerSources/Sources/AST/Declarations.swift

SwiftCompilerSources/Sources/SIL/Type.swift

SwiftCompilerSources/Sources/AST/Declarations.swift

SwiftCompilerSources/Sources/AST/DeclContext.swift

SwiftCompilerSources/Sources/AST/Declarations.swift

kovdan01 · 2025-11-17T22:50:30Z

@eeckstein Thanks for your feedback and detailed explanation for your suggestions! I believe the latest changes I've just submitted should address your comments.

eeckstein

lgtm, nice work!

kovdan01 · 2025-11-18T15:05:07Z

@swift-ci please test

kovdan01 · 2025-11-18T19:51:53Z

@swift-ci please test

kovdan01 · 2025-11-19T01:26:19Z

@swift-ci please test

kovdan01 · 2025-11-19T08:45:36Z

@swift-ci please test Linux platform

kovdan01 · 2025-11-19T13:21:53Z

@swift-ci please test Linux platform

kovdan01 · 2025-11-19T20:14:43Z

@swift-ci please test Linux platform

aidan-hall · 2025-11-20T14:45:21Z

I'm working on some changes that depend on this PR, so I'm going to merge it. I hope that's OK. Thanks for the contribution!

kovdan01 · 2025-11-20T16:09:34Z

I'm working on some changes that depend on this PR, so I'm going to merge it. I hope that's OK. Thanks for the contribution!

@aidan-hall Ah, I've just finished an updated version of the PR description, but it was anyway too long and probably not that useful. So yeah, I hope that nobody is too worried about this being merged with a short description w/o too much details.

kovdan01 requested a review from asl October 2, 2025 14:49

kovdan01 force-pushed the users/kovdan01/ast-bridges-for-autodiff-closure-spec branch from 10085d6 to b3d31c7 Compare October 6, 2025 14:58

kovdan01 added the bridging Feature → casting: type bridging label Oct 6, 2025

kovdan01 marked this pull request as ready for review October 6, 2025 15:09

kovdan01 requested review from CodaFi, bnbarham, eeckstein, hamishknight, hborla, jckarter, rintaro, slavapestov and xedin as code owners October 6, 2025 15:09

eeckstein marked this pull request as draft October 6, 2025 16:23

eeckstein requested changes Oct 7, 2025

View reviewed changes

rintaro reviewed Oct 8, 2025

View reviewed changes

include/swift/AST/ASTBridging.h Outdated Show resolved Hide resolved

kovdan01 added 2 commits October 15, 2025 05:14

Address review comments

02fcd21

Merge branch 'main' into users/kovdan01/ast-bridges-for-autodiff-clos…

7c90f03

…ure-spec

kovdan01 commented Oct 15, 2025

View reviewed changes

kovdan01 requested review from eeckstein and rintaro October 15, 2025 18:07

eeckstein reviewed Oct 21, 2025

View reviewed changes

kovdan01 added 2 commits November 10, 2025 18:46

Merge branch 'main' into users/kovdan01/ast-bridges-for-autodiff-clos…

72431db

…ure-spec

Resolve merge conflicts & address review comments

f0bf57a

kovdan01 commented Nov 10, 2025

View reviewed changes

kovdan01 requested a review from eeckstein November 10, 2025 17:03

eeckstein reviewed Nov 13, 2025

View reviewed changes

kovdan01 added 2 commits November 17, 2025 10:22

Merge branch 'main' into users/kovdan01/ast-bridges-for-autodiff-clos…

c1f4bcf

…ure-spec

Address review comments

c12819f

kovdan01 commented Nov 17, 2025

View reviewed changes

kovdan01 requested a review from eeckstein November 17, 2025 11:25

eeckstein reviewed Nov 17, 2025

View reviewed changes

SwiftCompilerSources/Sources/AST/DeclContext.swift Show resolved Hide resolved

SwiftCompilerSources/Sources/AST/DeclContext.swift Show resolved Hide resolved

SwiftCompilerSources/Sources/AST/Declarations.swift Outdated Show resolved Hide resolved

Address review comments

a172134

kovdan01 requested a review from eeckstein November 17, 2025 22:50

eeckstein approved these changes Nov 18, 2025

View reviewed changes

kovdan01 marked this pull request as ready for review November 18, 2025 15:04

Fix build

c0935fc

Fix build

5bd3d80

aidan-hall mentioned this pull request Nov 19, 2025

PackSpecialization: Fix result & type parameter handling #85456

Open

aidan-hall merged commit 2c9013b into main Nov 20, 2025
5 checks passed

aidan-hall deleted the users/kovdan01/ast-bridges-for-autodiff-closure-spec branch November 20, 2025 14:45

aidan-hall restored the users/kovdan01/ast-bridges-for-autodiff-closure-spec branch November 21, 2025 10:51

	/// Clone the generic parameters of the given generic signature and return a new
	/// `GenericParamList`.
	static GenericParamList *cloneGenericParameters(ASTContext &ctx,
	DeclContext *dc,
	CanGenericSignature sig) {
	SmallVector<GenericTypeParamDecl *, 2> clonedParams;
	for (auto paramType : sig.getGenericParams()) {
	auto *clonedParam = GenericTypeParamDecl::createImplicit(
	dc, paramType->getName(), paramType->getDepth(), paramType->getIndex(),
	paramType->getParamKind());
	clonedParam->setDeclContext(dc);
	clonedParams.push_back(clonedParam);
	}
	return GenericParamList::create(ctx, SourceLoc(), clonedParams, SourceLoc());
	}

	BridgedType BridgedFunction::getLoweredType(BridgedASTType type, bool maximallyAbstracted) const {
	if (maximallyAbstracted) {
	return BridgedType(getFunction()->getLoweredType(swift::Lowering::AbstractionPattern::getOpaque(), type.type));
	}
	return BridgedType(getFunction()->getLoweredType(type.type));
	}

	BridgedType BridgedFunction::getLoweredType(BridgedType type) const {
	return BridgedType(getFunction()->getLoweredType(type.unbridged()));
	}

	/// Returns the lowered SIL type of the branching trace enum associated with
	/// the given original block.
	SILType getBranchingTraceEnumLoweredType(SILBasicBlock *origBB) const {
	auto *traceDecl = getBranchingTraceDecl(origBB);
	auto traceDeclType =
	traceDecl->getDeclaredInterfaceType()->getCanonicalType();
	Lowering::AbstractionPattern pattern(
	derivative->getLoweredFunctionType()->getSubstGenericSignature(),
	traceDeclType);
	return typeConverter.getLoweredType(pattern, traceDeclType,
	TypeExpansionContext::minimal());
	}


		public typealias FileUnit = BridgedFileUnit

		public typealias GenericParamList = BridgedGenericParamList


		public typealias TrailingWhereClause = BridgedTrailingWhereClause

		public typealias BridgedParamDecl = ASTBridging.BridgedParamDecl

Bridging: Implement bridges required for ongoing AutoDiff changes #84648

Bridging: Implement bridges required for ongoing AutoDiff changes #84648

Uh oh!

Conversation

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

Uh oh!

Uh oh!

kovdan01 commented Oct 2, 2025

Uh oh!

asl commented Oct 2, 2025

Uh oh!

kovdan01 commented Oct 6, 2025

Uh oh!

kovdan01 commented Oct 6, 2025

Uh oh!

eeckstein commented Oct 6, 2025

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kovdan01 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

eeckstein left a comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

kovdan01 commented Oct 2, 2025 •

edited

Loading