Give BuiltinProtocolConformance a generic signature, which can be used to
describe the generic parameters used within the builtin conformance, e.g.,
`<T1, T2, T3>` for a tuple type `(T1, T2, T3)`. Also store the
conditional requirements as trailing objects, requiring them to be
precomputed by whatever builds the conformances. Together, this means
that builtin protocol conformances act like normal conformances with
respect to conditional requirements and substitutions: they will be
defined generically, then a specialized conformance will be layered on
top to provide the substitutions.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
This code path can report compiler inconsistencies, so let's make the
pretty stacktrace more useful when debugging. We probably want to make
the assert on witness.getDecl() a hard error too, but this would break
existing projects at this time.
Parse and provide semantic checking for '@unchecked Sendable', for a
Sendable conformance that doesn't perform additional semantic checks
for correctness.
Part of rdar://78269000.
Foundation imports CoreFoundation with `@_implementationOnly`,
so CoreFoundation's modulemap won't be read, and the dependent libraries
of CoreFoundation will not be automatically linked when using static
linking.
For example, CoreFoundation depends on libicui18n and it's modulemap has
`link "icui18n"` statement. If Foundation imports CoreFoundation with
`@_implementationOnly` as a private dependency, the toolchain doesn't have
CoreFoundation's modulemap and Foundation's swiftmodule doesn't import
CoreFoundation. So the swiftc can't know that libicui18n is required.
This new option will add LINK_LIBRARY entry in swiftmodule to
specify dependent libraries (in the example case, Foundation's
swiftmodule should have LINK_LIBRARY entry of libicui18n)
See also: [Autolinking behavior of @_implementationOnly with static linking](https://forums.swift.org/t/autolinking-behavior-of-implementationonly-with-static-linking/44393)
When allowing errors any attribute could be on any decl, so don't verify
whether an attribute can appear on a decl. Note that these attributes
aren't serialized anyway since they'll be set to invalid during
typechecking and hence skipped.
A normal compilation would error before merging modules when there are
MissingMemberDecls, so the missing member case is unreachable. That's
not true when allowing errors though, where we continue regardless. Skip
the missing member instead of crashing.
Resolves rdar://76365694.
When compiling with allow errors, it's possible to have invalid
inherited types - both null and ErrorType.
Cleaned up the tests a little - moved the majority of
Frontend/allow-errors.swift into separate files in
Serialization/AllowErrors and use split_file.py instead of #defines.
Resolves rdar://78048470
If the `-static` option is specified, store that in the generated
swiftmodule file. When de-serializing, recover this information in the
representative SILModule.
This will be used for code generation on Windows. It is the missing
piece to allow static linking to function properly. It additionally
opens the path to additional optimization on ELF-ish targets - GOT, PLT
references can be avoided when the linked module is known to be static.
Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
This allows library authors to pass down a project version number so that library users can conditionally
import that library based on the available version in the search paths.
Needed for rdar://73992299
Mark imported `@completionHandlerAsync` attrs as
implicit, which avoids printing them in generated
interfaces. And for the sake of completion,
serialize the implicit bit in case it's used
elsewhere in the future.
To make sure we continue to print
`@completionHandlerAsync` attributes explicitly
written by the user in Swift, add a SourceKit
interface test.
Resolves rdar://76685011
When allowing errors there's various cases where an invalid type is used
during serialization:
- Invalid explicit conformances on an extension
- Superclass with invalid generic type
Add checks to skip these to avoid crashing.
Resolves rdar://75379780.
Since 865e80f9c4 we are keeping track of internal closure labels in the closure’s type. With this change, wer are also serializing them to the swiftmodules.
Furthermore, this change adjusts the printing behaviour to print the parameter labels in the swiftinterfaces.
Resolves rdar://63633158
Introduce the notion of global actor-qualified function types, e.g.,
@MainActor () -> Void
to describe synchronous functions that must execute on a particular
global actor.
Assuming that we don't typecheck a deserialized module, we don't
actually need the ExplicitCompletionHandlerIndex. We used this flag to
determine whether we could trust the number stored in the handler index
or just take the last parameter of the function we're attached to.
Since we only typecheck it before serialization, we can safely check
that the completion handler location is valid before choosing whether we
should trust it or not.
We can get the DeclName of the async function from the resolved function
decl itself, so we don't actually need to serialize it. This patch pulls
the declNameRef from the serialization.
This patch replaces the @hasAsyncAlternative attribute with
@completionHandlerAsync. The @completionHandlerAsync attribute takes the
function decl name of the async function and optionally the index of the
completion hander parameter in the function that it's attached to.
If the completion handler index is not provided, it's assumed to be the
last parameter in the parameter list.
We resolve the async function while typechecking the attribute. Before
resolving, we verify that the function the attribute is attached to
isn't async, that it has enough parameters to at least have the
indicated completion handler referenced by the index, that the
completion handler is an escaping non-auto-closure function that returns
Void.
The async function declaration resolution isn't perfect yet, but I want
to get this patch up and we can refine it later. It pulls all of the
delcs with the specified declname in the same context as the
function that the attribute is attached to. Going through that list, it
keeps any that are async functions. If there are none, we emit an error
saying that there are no viable functions, if there are multiple we emit
an error saying that the decl name is ambiguous, and if there is one
function, we keep that as the resolve async function declaration.
This does not take into account the data types of the completion handler
or the async function. There are some complexities to making this
mapping. Here are the pieces:
- If the completion handler takes a single data type, the async
function should return that type. (easy case)
- If the completion handler takes a `Result<T, Error>`, the async
function is a throwing function that returns a T. (Medium difficulty)
- If the completion handler looks like `(T?, Error?) -> Void`, we have
an ambiguous situation between the following async functions:
- func foo() async throws -> T
- func foo() async throws -> T?
That is, we cannot tell whether the `T?` in the completion handler is
optional because it will be nil on an error, or if it is intended to
be optional.
This can be done later if it becomes a problem.
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
When the user spells an invalid precedence group, the Relation for that
group will fail to resolve the decl. We need to handle this in
checkPrecedenceGroup. Also add some asserts while I'm here.
rdar://75248642
47b068d445 output a diagnostic if a
deserialized decl was invalid (checking `Decl::isInvalid`). It had two
major issues:
1. It incorrectly output diagnostics for valid modules
2. It did not catch call invalid declarations
(1) is caused by `isInvalid` falling back to checking the storage for
accessors when the interface type hasn't already been computed (a
fallback to prevent a cycle due to `SimpleDidSetRequest` typechecking
the body). Since the `VarDecl` hasn't finished deserializing, it returns
`true` for its `isInvalid` check (even though it would later return
`false`).
For (2), only `ValueDecl`s would ever be invalid, since other
declarations use a bit in `Decl` to check for validity. As that's not
serialized, those would always be valid in deserialization.
To avoid both these issues, instead output a flag for each declaration
representing whether it is invalid (or not). Read that during
deserialization and output a diagnostic if it is invalid. To be extra
sure that a diagnostic is always output on an error, also output one
when deserializing any `ErrorType`. This ensures that SILGen does not
run when allowing errors (and an error is present), as it is likely to
crash when presented with an invalid AST.
Resolves rdar://74541834
