We saw this failure with a Clang module imported @_implementationOnly
with synthesized conformances by the ClangImporter. It caused
issues only in sil-opt as it reads all the witness tables.
rdar://problem/58924131
This cleanup exposed a problem with deserialization recovery and
property wrappers. If deserializing a property backed by a wrapper
failed, the lazy member lookup would fail, but subsequently a
loadAllMembers() call would still load the property.
This behavior is actually incorrect, because silently dropping a
stored property of a @frozen struct can result in miscompiles.
I've filed rdar://59403542 and rdar://59403617 to track fixing this.
In the meantime, I've tweaked the logic a bit to preserve the old
behavior.
Remove the option to switch off nested types tables. In a world where
re-entrant direct lookup will cause deserialization to fail (or worse),
disabling these tables will only lead to further instability in the
compiler.
As part of this, we have to change the type export rules to
prevent `@convention(c)` function types from being used in
exported interfaces if they aren't serializable. This is a
more conservative version of the original rule I had, which
was to import such function-pointer types as opaque pointers.
That rule would've completely prevented importing function-pointer
types defined in bridging headers and so simply doesn't work,
so we're left trying to catch the unsupportable cases
retroactively. This has the unfortunate consequence that we
can't necessarily serialize the internal state of the compiler,
but that was already true due to normal type uses of aggregate
types from bridging headers; if we can teach the compiler to
reliably serialize such types, we should be able to use the
same mechanisms for function types.
This PR doesn't flip the switch to use Clang function types
by default, so many of the clang-function-type-serialization
FIXMEs are still in place.
Add another cross-cutting module configuration to the nested types table
search path. A module can have no overlay but also contain a nested
types table suitable for finding a given member name. UIKit is the
sharpest example of this state of affairs. UIKit currently defines an
overlay in Swift where we find some nested types. But it also defines
an inner module that has some other nested types tables.
Resolves rdar://58940989
The current way that VarDecl::isLazilyInitializedGlobal() is implemented does
not work in the debugger, since the DeclContext of all VarDecls are deserialized
Swift modules. By adding a bit to the VarDecl we can recover the fact that a
VarDecl was in fact a global even in the debugger.
<rdar://problem/58939370>
The `@noDerivative` attribute marks the non-differentiability parameters of a
`@differentiable` function type. All parameters except those marked with
`@noDerivative` are differentiability parameters.
For example, `@differentiable (Float, @noDerivative Float) -> Float` is only
differentiable with respect to its first parameter.
The `@noDerivative` attribute is represented as a
`SILParameterDifferentiability` bit on `SILParameterInfo`.
Add round-trip serialization tests.
Resolves TF-872.
Motivation: `GenericSignatureImpl::getCanonicalSignature` crashes for
`GenericSignature` with underlying `nullptr`. This led to verbose workarounds
when computing `CanGenericSignature` from `GenericSignature`.
Solution: `GenericSignature::getCanonicalSignature` is a wrapper around
`GenericSignatureImpl::getCanonicalSignature` that returns the canonical
signature, or `nullptr` if the underlying pointer is `nullptr`.
Rewrite all verbose workarounds using `GenericSignature::getCanonicalSignature`.
Enable qualified declaration names in `@derivative` attribute, just like
`@transpose` attribute.
`DerivativeAttr` now stores a base type `TypeRepr *`, which is non-null for
parsed attributes that reference a qualified original declaration.
Add `TypeResolutionFlags::AllowModule` flag to enable module lookup via
`TypeChecker::lookupMember` given a `ModuleType`.
Add tests for type-qualified and module-qualified declaration names.
Resolves TF-1058.
Upstream `@derivative` attribute serialization/deserialization.
Test all original declaration kinds and various `wrt:` parameter clauses.
Resolves TF-837.
State the previously unstated nested type requirement that CodingKeys adds to the witness requirements of a given type. The goal is to make this member cheap to synthesize, and independent of the expensive protocol conformance checks required to append it to the member list.
Further, this makes a clean conceptual separation between what I'm calling "nested type requirements" and actual type and value requirements.
With luck, we'll never have to use this attribute anywhere else.
Complete the refactoring by splitting the semantic callers for the original decl of a dynamically replaced declaration.
There's also a change to the way this attribute is validated and placed. The old model visited the attribute on any functions and variable declarations it encountered in the primary. Once there, it would strip the attribute off of variables and attach the corresponding attribute to each parsed accessor, then perform some additional ObjC-related validation.
The new approach instead leaves the attribute alone. The request exists specifically to perform the lookups and type matching required to find replaced decls, and the attribute visitor no longer needs to worry about revisiting decls it has just grafted attributes onto. This also means that a bunch of parts of IRGen and SILGen that needed to fan out to the accessors to ask for the @_dynamicReplacement attribute to undo the work the type checker had done can just look at the storage itself. Further, syntactic requests for the attribute will now consistently succeed, where before they would fail dependending on whether or not the type checker had run - which was generally not an issue by the time we hit SIL.
To support lazy resolution of the cross-referenced function in a serialized @_dynamicReplacement(for: ...) attribute, add a utility to the LazyMemberLoader and plumb it through. This is a more general utility than the current resolver, which relies on the type checker to strip the attribute off of VarDecls and fan it back out onto accessors, which means serialization has only ever seen AbstractFunctionDecls.
We need this attribute to teach compiler to use a different name from the current
module name when generating runtime symbol names for a declaration. This is to serve
the workflow of refactoring a symbol from one library to another without breaking the existing
ABI.
This patch focuses on parsing and serializing the attribute, so @_originallyDefinedIn
will show up in AST, swiftinterface files and swiftmodule files.
rdar://55268186
Add an alternative to getTopLevelDecls and getDeclChecked to limit which
decls are deserialized by first looking at their attributes. If the
attributes are accepted by a function passed as argument the decl is
fully deserialized, otherwise it is ignored.
The filter is included in the signature of existing functions in the
Serilalization services, but I’ve added new methods for it in FileUnit
and its subclasses to leave existing implementations untouched.
* Fix Swift following bitstream reader API update
Upstream change in rL364464 broke downstream Swift.
(cherry picked from commit 50de105bf1)
Conflicts:
lib/Serialization/Deserialization.cpp
lib/Serialization/ModuleFile.cpp
tools/driver/modulewrap_main.cpp
Witness matching is a source of a lot of ad-hoc cycles, and mixes the
logic that performs resolution, caching, validation, and cycle detection into one
place. To make matters worse, some checkers kick off other checks in
order to cache work for further declarations, and access an internal
cache on their subject conformance for many requirements at once, or
sometimes just one requirement.
None of this fits into the request evaluator's central view of the
caching. This is further evidenced by the fact that if you attempt to
move the caching step into the evaluator, it overcaches the same
witness and trips asserts.
As a start, define requests for the resolution steps, and flush some
hacks around forcing witness resolution. The caching logic is mostly
untouched (the requests don't actually cache anything), but some cycle
breaking is now handled in the evaluator itself. Once witness matching
has been refactored to cache with the evaluator, all of these hacks can
go away.
My urge to destroy the LazyResolver outweighs the compromises here.
This non-user-facing attribute is used to denote pointer parameters
which do not accept pointers produced from temporary pointer conversions
such as array-to-pointer, string-to-pointer, and in some cases
inout-to-pointer.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
