You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a cherry-pick of
PR#58642
PR#58687
PR#58701
PR#58723
PR#58760
PR#58642 Eager specializer: Fix pre-specialization of imported code
We must no pre-specialize imported code (except if this was explicitly
called for by the importing module).
Therefore, don't pre-specialize `shared` definitions based on their
pre-specialization attributes.
Rather, only pre-specialize if the pre-specialization is called for
using a `target: "theFunctionToSpecialize"` parameter.
Run OnonePrespecializations before serialization so that module native functions
are not yet marked `shared` and can be identified as native.
rdar://92337361
PR#58687 CrossModuleOptimization: Don't serialize pre-specialized public entry points
We should continue to use the public pre-specialized entry point from another module. But not block other uses of generic specializations.
PR#58701 SILFunctionBuilder: Don't create [serialized] function post serialization
This might fix the randomly occuring errors of:
```
SIL verification failed: cannot have a serialized function after the module has been serialized: !F->isSerialized() || !mod.isSerialized() || mod.isParsedAsSerializedSIL()
```
PR#58723 GenericSpecialization: Move once initialization of pre-specializations earlier before the first query for pre-specialziations
PR#58760 swiftinterface: print _specialize functions with targetFunction parameter in .swiftinterface
If we have an internal function with a `_specialize` attribute that has
a `targetFunction:` parameter we want the function to appear in the
.swiftinterface file such that the exported specialization can be picked up by
the compiler.
0 commit comments