Add type checking for `@differentiable` function types:
- Check that parameters and results conform to `Differentiable`.
- Implicitly conform parameters and results whose types are generic parameters
to `Differentiable`.
- Upstream most of the differentiable_func_type_type_checking.swift test from
`tensorflow` branch. A few function conversion tests have not been added
because they depend on the `@differentiable` function conversion pipeline.
Diagnose gracefully when the `Differentiable` protocol is unavailable because
`_Differentiation` has not been imported.
Resolves TF-823 and TF-1219.
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
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`.
This inlines the comparators since GCC 7 objects to the definition
(which is probably due to scoping). However, these methods are
templates, which must be visible to the consumers, and should therefore
be in the header. Given the size, it seems reasonable to just inline
them.
The lookupDirect means that we can see type declarations nested inside of a protocol. If we do not filter these invalid declarations, we will offer a bogus fixit on top of a cycle diagnostic. Remove these types from consideration entirely so we don't crash and don't offer bogus fixits.
Resolves rdar://57003317
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.
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
The GSB will try to form and note invalid constraints, but there are
a few paths that aren't prepared for error types to pop up. Add
a defensive check to formProtocolRelativeType to make sure we don't wind
up force-casting an error type.
Fixes rdar://56116278
TypeCheckPattern used to splat the interface type into this, and
different parts of the compiler would check one or the other. There is
now one source of truth: The interface type. The type repr is now just
a signal that the user has written an explicit type annotation on
a parameter. For variables, we will eventually be able to just grab
this information from the parent pattern.
This relied on UB as per [meta.rqmts]p4
(http://eel.is/c++draft/meta#rqmts-4) and has been UB since C++11
20.9.2p1 has the same restriction.
MSVC 19.24 became more stringent and silently ignores this now,
preventing the Swift build. Require the user to explicitly pass in
`-DSWIFT_PERMIT_UNDEFINED_BEHAVIOR` to get the dump functionality.
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.
Remove the parent signature from consideration when computing the
generic signature for an extension. This cuts off a series of crashers
that involved nested extensions with trailing where clauses a la
extension Foo {
extension Foo where Self.Undefined == Bar {
}
}
The inner (invalid) extension technically has a parent signature from
Foo itself. Adding that signature to the GSB means when we go to
register the inner extension's generic parameters we crash.
Since extensions have to occur at the top level, just remove the parent
signature from consideration.
Fixes rdar://55502661
