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.
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.
* [CSDiagnostics] Emit fix-its to insert requirement stubs in editor mode for missing protocols in context
* [CSDiagnostics] Only include missing requirements in stub fix-it for missing protocols in context
The conforming type may already have declarations that could satisfy a requirement, so we shouldn't include it in the fix-it
VS2015 had an issue with the deletion of an operator. Since VS2017 is
the minimum version that LLVM uses, we can assume that VS2017+ is in use
(_MSC_VER >= 1910). Clean up the now defunct workaround.
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.
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.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
First, remove the AvailabilityContext parameter; it was confusing because
we actually always want to use the deployment target here.
Then, split this method up into three methods:
- isAlwaysWeakImported(): simply checks for a @_weakLinked attribute, either
on the declaration itself or one of its parent contexts.
- getAvailabilityForLinkage(): returns the OS version availability when
this declaration was introduced, or if the declaration does not have
explicit availability, check it's storage (if its an accessor), or its
parent contexts.
- isWeakImported(ModuleDecl *fromModule): combines these two checks to
determine if the declaration should be weak linked when referenced from
the given module, or if it might be weak referenced from some module
(if the module parameter is null).
We've fixed a number of bugs recently where callers did not expect
to get a null Type out of subst(). This occurs particularly often
in SourceKit, where the input AST is often invalid and the types
resulting from substitution are mostly used for display.
Let's fix all these potential problems in one fell swoop by changing
subst() to always return a Type, possibly one containing ErrorTypes.
Only a couple of places depended on the old behavior, and they were
easy enough to change from checking for a null Type to checking if
the result responds with true to hasError().
Also while we're at it, simplify a few call sites of subst().
Now that ensureRequirementsAreSatisfied() is never called with
failUnsubstituted == false, remove all the logic for deferring
checking of a conformance against the requirement signature of
its protocol.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
...even if the conforming nominal type is resilient. It's the owner
of the conformance whose resilience matters.
I also factored this part out into a separate check at the AST level
so we can tweak it, and also so I can use it to (slightly) speed up
compiling a resilient swiftinterface.
Witness table accessors return a witness table for a given type's
conformance to a protocol. They are called directly from IRGen
(when we need the witness table instance) and from runtime conformance
checking (swift_conformsToProtocol digs the access function out of the
protocol conformance record). They have two interesting functions:
1) For witness tables requiring instantiation, they call
swift_instantiateWitnessTable directly.
2) For synthesized witness tables that might not be unique, they call
swift_getForeignWitnessTable.
Extend swift_instantiateWitnessTable() to handle both runtime
uniquing (for #2) as well as handling witness tables that don't have
a "generic table", i.e., don't need any actual instantiation. Use it
as the universal entry point for "get a witness table given a specific
conformance descriptor and type", eliminating witness table accessors
entirely.
Make a few related simplifications:
* Drop the "pattern" from the generic witness table. Instead, store
the pattern in the main part of the conformance descriptor, always.
* Drop the "conformance kind" from the protocol conformance
descriptor, since it was only there to distinguish between witness
table (pattern) vs. witness table accessor.
* Internalize swift_getForeignWitnessTable(); IRGen no longer needs to
call it.
Reduces the code size of the standard library (+assertions build) by
~149k.
Addresses rdar://problem/45489388.
In one test where we used to dump conditional requirements we now print
a message that they have not been computed yet. I couldn't come up with
a way to force them to be computed here, but for the most part this test
is just ensuring that we don't recurse forever when printing recursive
conformances.
This doesn't fix the fundamental problem of correctly handling such cases, but
it is better than the "error message" that occurred previously:
Assertion failed: ((bool)typeSig == (bool)extensionSig && "unexpected generic-ness mismatch on conformance").
Fixes the crash rdar://problem/41281406 (that in
https://bugs.swift.org/browse/SR-6569 (rdar://problem/36068136)),
https://bugs.swift.org/browse/SR-8019 (rdar://problem/41216423) and
https://bugs.swift.org/browse/SR-7989 (rdar://problem/41126254).
Introduced during the bring-up of the generics system in July, 2012,
Substitution (and SubstitutionList) has been completely superseded by
SubstitutionMap. R.I.P.
A "retroactive" protocol conformance is a conformance that is provided
by a module that is neither the module that defines the protocol nor
the module that defines the conforming type. It is possible for such
conformances to conflict at runtime, if defined in different modules
that were not both visible to the compiler at the same time.
When mangling a bound generic type, also mangle retroactive protocol
conformances that were needed to satisfy the generic requirements of
the generic type. This prevents name collisions between (e.g.) types
formed using retroactive conformances from different modules. The
impact on the size of the mangling is expected to be relatively small,
because most conformances are not retroactive.
Fixes the ABI part of rdar://problem/14375889.
Protocol conformance records are becoming richer and more interesting;
separate out the "flags" word and add the various other fields that we
want there (is-retroactive, is-synthesized-nonunique, # of conditional
requirements).
Rather than storing contextual types in the type witnesses and associated
conformances of NormalProtocolConformance, store only interface types.
@huonw did most of the work here, and @DougGregor patched things up to
complete the change.
This allows determining which requirements make a conformance conditional; as
in, which requirements aren't known as part of the type itself.
Additionally, use this to assert that a few builtin protocols aren't
conditionally-conformed-to, something we won't support for now.
When setting the signature conformances in a NormalProtocolConformance,
do so progressively rather than waiting until all of them are computed.
This allows later requirements to refer to earlier conformances.
In almost all other places, 'resolver' means the ASTContext's LazyResolver,
which is just an abstract base class for the TypeChecker instance to break
circularity.
But here it is something totally different, used to lazily populate
imported and deserialized conformances, not parsed conformances.
Previously, the importer queued up conformances to complete once it
was done importing the current batch of declarations. However, if
there was a serialized Swift module that extended an imported type to
add a conformance in exactly the wrong way, the importer could end up
asking for that conformance later---even before the reference to the
imported type was resolved. This led to a crash in the deserializer
"while reading conformance for type X".
Instead of this "pending actions" queue, we can just use the
mechanisms already in place for lazily loading conformances. That way
they'll get filled out on demand, which is better all around anyway.
This does mean putting the requirement signature into the "lazy" part
of the conformance, though.
This does as a side effect mean that /all/ of the witnesses for the
imported conformance may be opaque---that is, they will never be
devirtualized to a particular implementation. However, they previously
would have referred to methods implemented in Objective-C anyway,
which are always dispatched with objc_msgSend. So this should have no
practical effect.
rdar://problem/32346184
