Previously, two conditions were necessary to enable differentiable programming:
- Using the `-enable-experimental-differentiable-programming` frontend flag.
- Importing the `_Differentiation` module.
Importing the `_Differentiation` module is the true condition because it
contains the required compiler-known `Differentiable` protocol. The frontend
flag is redundant and cumbersome.
Now, the frontend flag is removed.
Importing `_Differentiation` is the only condition.
When a Swift declaration witnesses an ObjC protocol requirement, its error convention needs to
match the requirement. Furthermore, if there are different protocol requirements that the
Swift method can witness, with different error conventions, we need to bail out because we
can't simultaneously match all of them. Fixes rdar://problem/59496036 | SR-12201.
Several declarations must be at least partially deserialized before their names can be determined. Add those names to pretty stack traces to make deserialization crashes easier to debug.
We don’t test pretty stack traces, so this doesn’t contain any test changes.
The ContextualizeClosures walker re-parents and assigns discriminators to
autoclosures. We weren't doing this walk for function builder bodies,
which meant that proper invariants were not being established for the
implicit autoclosures synthesized for partially applied method references.
This is a recent regression from my change to build curry thunks for
unapplied method references in Sema.
Fixes <rdar://problem/61039516>.
Type layout based witness generation can emit quite complex IR that will
lead to code bloat if the llvm optimizer is not run.
No need to use type layouts at Onone.
rdar://61155295
This avoids significant code size regressions if the loop block to be duplicated is very large.
Also remove the ShouldRotate option. It's not needed anymore as disabling the pass can be done by -sil-disable-pass.
rdar://problem/33970453
Otherwise, we would generate inconsistent vtable layouts for classes
with static properties that have attached wrappers. The reason is that
we normally force synthesis of the backing storage and storage wrapper
for each instance property wrapper as part of computing the lowered
stored properties.
However, there was no such forcing for static properties. But since a
static stored property (with an attached wrapper or otherwise) must be
'final', the real fix is to just ensure that the 'final' bit propagates
to the storage wrapper as well.
The backing storage property was already always final, so the issue
did not arise there.
Fixes <rdar://problem/59522703>, <https://bugs.swift.org/browse/SR-12429>.
Solver has to keep track of excluded dynamic member results while
performing lookup because otherwise, in diagnostic modem it might
include such results as inaccessible.
Resolves: rdar://problem/61084565
* Document a number of legacy conditions and edge cases
* Add lexicon definitions for "dependency source", "dependency sink",
"cascading dependency" and "private dependency"
Convert most of the name lookup requests and a few other ancillary typechecking requests into dependency sinks.
Some requests are also combined sinks and sources in order to emulate the current scheme, which performs scope changes based on lookup flags. This is generally undesirable, since it means those requests cannot immediately be generalized to a purely context-based scheme because they depend on some client-provided entropy source. In particular, the few callers that are providing the "known private" name lookup flag need to be converted to perform lookups in the appropriate private context.
Clients that are passing "no known dependency" are currently considered universally incorrect and are outside the scope of the compatibility guarantees. This means that request-based dependency tracking registers strictly more edges than manual dependency tracking. It also means that once we fixup the clients that are passing "known private", we can completely remove these name lookup flags.
Finally, some tests had to change to accomodate the new scheme. Currently, we go out of our way to register a dependency edge for extensions that declare protocol conformances. However, we were also asserting in at least one test that extensions without protocol conformances weren't registering dependency edges. This is blatantly incorrect and has been undone now that the request-based scheme is automatically registering this edge.
Request-based incremental dependencies are enabled by default. For the time being, add a flag that will turn them off and switch back to manual dependency tracking.
* [Diagnostics] Emit a warning when an immutable decodable property has an initial value
* [Sema] Use Decl::diagnose instead of Diags.diagnose
* [AST] Remove property name from 'decodable_property_will_not_be_decoded' diagnostic
* [Test] Update tests
* [Test] Update existing codable tests
Some protocols, such as protocols marked with 'objc', do not have a Witness Table.
The code before this patch assumes all protocols do have a Witness Table when generating the layout of an OpaqueTypeDescriptor, causing an assert to be triggered for opaque return types that conform to an 'objc' protocol.
Fixes SR-12257 / rdar://problem/59740179
A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
A partial_apply of a function_ref whose body consists of just an
apply of a witness_method can be simplified down to a simple
partial_apply of the witness_method:
sil @foo:
%fn = witness_method ...
%result = apply %fn(...)
return %result
sil @bar:
%fn = function_ref @foo
%closure = partial_apply %fn(...)
===>
sil @bar:
%fn = witness_method ...
%closure = partial_apply %fn(...)
Type on the right-hand side of the element conversion/pattern match
should be allowed to have holes to be able to diagnose failures with
structurally incompatible types.
Resolves: rdar://problem/60832876
* Add all [differential operators](https://github.com/apple/swift/blob/master/docs/DifferentiableProgramming.md#list-of-differential-operators).
* Add `withoutDerivative(at:)`, used for efficiently stopping the derivative propagation at a value and causing the derivative at the value to be zero.
* Add utility `differentiableFunction(from:)`, used for creating a `@differentiable` function from an original function and a derivative function.
Mostly work done by @marcrasi and @dan-zheng.
Partially resolves TF-843.
TODO:
* Add `AnyDerivative`.
* Add `Array.differentiableMap(_:)` and `differentiableReduce(_:_:)`.
