Instead, stimulate users to follow the referenced bug reporting guidelines,
which contain all the necessary information. We’d rather encourage attempts
at reducing issues before attaching Xcode projects. This is an accompaniment
to https://github.com/apple/swift-org-website/pull/158.
Many deserialization failures at this points are caused by archives
installed over the SDK. Let's extend the current error message with a
solution for such a case.
rdar://86280699
The old syntax was
@opened("UUID") constraintType
Where constraintType was the right hand side of a conformance requirement.
This would always create an archetype where the interface type was `Self`,
so it couldn't cope with member types of opened existential types.
Member types of opened existential types is now a thing with SE-0309, so
this lack of support prevented writing SIL test cases using this feature.
The new syntax is
@opened("UUID", constraintType) interfaceType
The interfaceType is a type parameter rooted in an implicit `Self`
generic parameter, which is understood to be the underlying type of the
existential.
Fixes rdar://problem/93771238.
Introduce a `getTopmostDeclarationDeclContext`
utility to ensure we ensure we don't visit a
`nullptr` DeclContext for an erroneous module
under `-experimental-allow-module-with-compiler-errors`.
Additionally, tweak the insertion location such
that we insert at the start of any attributes
present.
rdar://97267326
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
This is important for performance diagnostics: it’s assumed that (non-generic) MemoryLayout constants do not need to create metadata at runtime. At Onone this is only guaranteed if the TargetConstantFolding pass runs.
rdar://94836837
Only production compilers should apply the per-SDK restriction on
loading swiftmodules. Use the "is the compiler tagged" information over
a release build to align with the other main swiftmodule loading
restriction accepting only swiftmodules built by the same tag.
Also use an env var SWIFT_DEBUG_FORCE_SWIFTMODULE_PER_SDK to enable
testing this feature in any compilers.
Change the way swiftmodules built against a different SDK than their
clients are rejected. This makes them silently ignored when the module
can be rebuilt from their swiftinterface, instead of reporting a hard
error.
rdar://93257769
Clean up a thinko in the original deserialization code by making
the TypeDeserializer aware of parameterized existential types. The
deserialization code paths are already in place, we're just not
calling them!
rdar://93062561
We didn't serialize the ownership kind, which resulted in a miscompile causing an over-release.
The unchecked_ref_cast is the only instruction for which we change the ownership in the optimizer, so that it doesn't match the operand's ownership. Therefore this fix is sufficient for now - we don't need to serialize the ownership of other instructions.
But this is really a design flaw of the `OwnershipForwardingMixin`. It should not allow to set the ownership to arbitrary values.
rdar://92696202
When restricting loading swiftmodules to the SDK used to build them,
an exception should be made for modules built against an SDK that is a subset
of the SDK used when loading the module. In such a case, the swiftmodule
file is more reliable.
rdar://92827584
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
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
The resignID call within the initializer moved into DI, because an assignment to
the actorSystem, and thus initialization of the id, is no longer guaranteed to happen.
Thus, while we previously could model the resignation as a clean-up emitted on all
unwind paths in an initializer, now it's conditional, based on whether the id was
initialized. This is exactly what DI is designed to do, so we inject the resignation
call just before we call the identity's deinit.
Write the real module name for XRefs in swiftmodule files instead of the
exported module name, from `export_as` declarations in module maps.
Swiftmodule files are internal details now, they should represent the
truth.
We keep using the exported module name for the extensions lookup table
as clients should still use the exported name. However we may need to
write both alternatives in the lookup table in the future if extensions
can't be found from clients not importing the exported as module.
rdar://90272035
