We need reflection enabled as swift-collections uses this which is
required for Foundation. Adjust the defaults to allow building
Foundation for Android again.
When compiling for visionOS, iOS availability attributes are remapped into the
visionOS availability domain automatically. While the version remapping was
being performed correctly, there was a regression that caused the platform name
to be printed incorrectly in many diagnostics. Whenever an iOS version is
remapped to a visionOS version, availability diagnostics will now present
those versions as visionOS versions instead of iOS versions.
Resolves rdar://146293165.
While deserializing AST function types FunctionType and GenericFunctionType which include
lifetime dependencies and an implicit self parameter, we don't correctly populate
ASTExtInfoBuilder.lifetimeDependencies. We end up reading one dependency less due to
incorrect index calculation.
Unlike SILFunctionType, AST function types FunctionType and GenericFunctionType
do not include implicit self in their param list. They represent methods with
implicit self as like: `(Self) -> (Args...) -> Result` and don't have any information
to indicate they may have implicit self. Since we use number of parameters while
deserializing lifetime dependencies, we go wrong for such function types.
Serialize the length of parameter indices, so that lifetime dependencies can be
deserialized to that length.
rdar://151768216
getContextSubstitutionMap() didn't handle the case where getAnyNominal()
returns a ProtocolDecl. This should not take the "fast path", which is
only suitable for concrete nominals.
This manifested as a crash-on-invalid -- the user probably meant to write
"T.Value: Collection" rather than "T.Value == Collection".
Fixes rdar://151479861.
Building with the Windows static SDK uncovered issues in the Windows
module maps. Some of the headers were missing and others had incorrect
layering. This updates the module maps to build with the static Windows
SDK.
Textual interfaces for 'Darwin' built with recent compilers specify that it is built witout C++ interop enabled. However, to ensure compatibility with versions of the 'Darwin' module built with older compilers, we hard-code this fact. This is required to break the module cycle that occurs when building the 'Darwin' module with C++ interop enabled, where the underlying 'Darwin' clang module depends on C++ standard library for which the compiler brings in the 'CxxStdlib' Swift overlay, which depends on 'Darwin'.
String interpolations can end up being unsafe in the call to
appendInterpolation when it's provided with unsafe types. Move the
location of the proposed "unsafe" out to the string interpolation
itself in these cases, which properly suppresses the warning.
Fixes rdar://151799777.
When the compiler is building a module without a defined formal C++ interop mode (e.g. building a textual interface which specifies it was built without C++ interop enabled), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the Darwin module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules. The primary source module, as well as Swift textual module dependencies which were built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module.
This was previously fixed in the dependency scanner for explicitly-built modules in https://github.com/swiftlang/swift/pull/81415.
In this case, what is happening is that in SILGen, we insert implicit
DistributedActor.asLocalActor calls to convert a distributed actor to its local
any Actor typed form. The intention is that the actor parameter and result are
considered the same... but there is nothing at the SIL level to enforce that. In
this commit, I change ActorInstance (the utility that defines actor identity at
a value level) to look through such a call.
I implemented this by just recognizing the decl directly. We already do this in
parts of SILGen, so I don't really see a problem with doing this. It also
provides a nice benefit that we do not have to modify SILFunctionType to
represent this or put a @_semantic attribute on the getter.
NOTE: Generally, Sema prevents us from mixing together different actors. In this
case, Sema does not help us since this call is inserted implicitly by the
distributed actor implementation in SILGen. So this is not a problem in general.
rdar://152436817
Update swift-argument-parser to 1.5.1. This is motivated by a change to
the build system in 1.5.1 that is required to build
swift-argument-parser as part of swift-driver to enable static linking
on Windows. Pulling in this change will enable us to make further
progress towards enabling the early swift driver on Windows.
This just involved loosening some checks in the type checker so we stopped
erroring in the type checker and instead deferred to SIL level checks.
rdar://131136194
We carried over all unsupported: marks from task_priority test which seems to have had just racy behavior for ages. This test should be fine on arm64e, and especially, we must run it to verify the pointer auth of these APIs.
This allowed a pointer auth issue to slip through, so let's remedy this by actually running the test on those platforms.
These need to be defined always; we'll set them to "unknown" and "none"
respectively if they end up being something we don't understand.
rdar://150966361
When de-serializing a function and this function allocates a class, the methods of the de-serialized vtable must be handled, too.
Fixes an IRGen crash
rdar://152311945
There's no reason for these to ever be calls, so they should be
transparent instead of just aEIC. Also adds concrete versions of
comparisons with scalars, and filecheck tests to make sure these
generate 1-2 instruction sequences in release on arm64 (x86_64 is a
little trickier to test due to frame pointers, but if we get the right
codgen on arm64, in practice we do well on x86_64 for these too).
Also makes filecheck patterns for repeating initializers a bit more
robust.
