Consider an `@_alwaysEmitIntoClient` function and a custom derivative
defined
for it. Previously, such a combination resulted different errors under
different
circumstances.
Sometimes, there were linker errors due to missing derivative function
symbol -
these occurred when we tried to find the derivative in a module, while
it
should have been emitted into client's code (and it did not happen).
Sometimes, there were SIL verification failures like this:
```
SIL verification failed: internal/private function cannot be serialized or serializable: !F->isAnySerialized() || embedded
```
Linkage and serialization options for the derivative were not handled
properly,
and, instead of PublicNonABI linkage, we had Private one which is
unsupported
for serialization - but we need to serialize `@_alwaysEmitIntoClient`
functions
so the client's code is able to see them.
This patch resolves the issue and adds proper handling of custom
derivatives
of `@_alwaysEmitIntoClient` functions. Note that either both the
function and
its custom derivative or none of them should have
`@_alwaysEmitIntoClient`
attribute, mismatch in this attribute is not supported.
The following cases are handled (assume that in each case client's code
uses
the derivative).
1. Both the function and its derivative are defined in a single file in
one module.
2. Both the function and its derivative are defined in different files
which
are compiled to a single module.
3. The function is defined in one module, its derivative is defined in
another
module.
4. The function and the derivative are defined as members of a protocol
extension in two separate modules - one for the function and one for the
derivative. A struct conforming the protocol is defined in the third
module.
5. The function and the derivative are defined as members of a struct
extension in two separate modules - one for the function and one for the
derivative.
The changes allow to define derivatives for methods of `SIMD`.
Fixes#54445
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
In AutoDiff/Sema/differentiable_attr_type_checking.swift, we have a
couple of following FIXMEs:
```
// FIXME(TF-284): Fix unexpected diagnostic.
```
However, the diagnostic is expected for the case of public protocol
requirements: see description https://github.com/swiftlang/swift/pull/30629.
This PR removed the diagnostic for less-than-public-visible requirements,
and the FIXME was initially related to them.
It looks like that the FIXMEs present now are a result of copy-paste and
have no meaning, and the diagnostic is expected and should be present and
does not need to be removed.
Fixes#78609
Consider:
1. File struct.swift defining `struct Struct` with `static func max` member
2. File derivatives.swift defining `extension Struct` with custom derivative of the `max` function
3. File error.swift defining a differentiable function which uses `Struct.max`.
Previously, when passing error.swift as primary file and derivatives.swift as a secondary file to swift-frontend (and forgetting to pass struct.swift as a secondary file as well), an assertion failure was triggered.
This patch fixes the issue by adding a check against `ErrorType` in `findAutoDiffOriginalFunctionDecl` before calling `lookupMember`.
Co-authored-by: Anton Korobeynikov <anton@korobeynikov.info>
Based on feedback in PR https://github.com/swiftlang/swift/pull/69460, enabling indexing for synthesized decls because they are usable by users and make sense to appear in the indexstore.
Sets `synthesized` on some additional decls:
- derived `hashInto(...)`
- Objc properties and methods derived from Objc protocols
https://github.com/apple/swift/issues/67446
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of opaque types, instead
of disabling availability checking.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
Introduce the notion of "semantic result parameter". Handle differentiation of inouts via semantic result parameter abstraction. Do not consider non-wrt semantic result parameters as semantic results
Fixes#67174
The above referenced issue was causing a compiler crash when writing
differentiable protocols and corresponding implementers, without importing
the `_Differentiation` module.
Changes in this CR fix the issue by marking any `@differentiable`
attributes as invalid, if the `_Differentiation` module has not been
imported. This ignores the `@differentiable` attributes when the
protocol witnesses are being verified. Witness verification was previously
leading to an error (due to missing `@differentiable` attribute on the protocol
requirement implementer), and the corresponding diagnostic emission code was
then leading to a crash, because it was expecting the `_Differentiation`
module to be present.
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
Calling computeExtendedNominal() won't catch the case where the
extended type did not exist at extension binding time but then
appeared later, like an inferred associated type witness for
example.
* Lookup for custom derivatives in non-primary source files after typecheck is finished for the primary source.
This registers all custom derivatives before autodiff transformations and makes them available to them.
Fully resolves#55170
Add new `-print-ast-decl` frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.
The existing `-print-ast` option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.
When checking the viability of an original function candidate as specified in a `@derivative` attribute, a candidate's signautre can have more generic requirements than the required signature. Such cases need to be checked and diagnosed.
Resolves SR-15530 / rdar://85845512.
Improved diagnostic for when the registered derivative function and
the function it derivates (the original) differ in terms of
`static` declaration modifier usage. Suggesting as well a fix-it,
to either remove or add the `static` keyword.
The registered derivative needs to be marked as `static` in two cases:
1. When the original function is a constructor.
2. When the original function is static as well.
When the original function is an instance method, the registered derivative must be as well.
Resolves [SR-13152](https://bugs.swift.org/browse/SR-13152).
Do not mark synthesized `TangentVector` members as synthesized so that the type checker won't sort them. We would like tangent vector members to have the same order as the properties in the parent declaration.
Also add `typealias TangentVector = Self` to the synthesized `TangentVector` so that it will not need its own `Differentiable` conformance derivation.
Resolves SR-14241 / rdar://74659803.
Rename `move(along:)` to `move(by:)` based on the proposal feedback. The main argument for the change is that tangent vectors specify both a direction and a magnitude, whereas `along:` does not indicate that `self` is being moved by the specified magnitude.
Compiler:
- Add `Forward` and `Reverse` to `DifferentiabilityKind`.
- Expand `DifferentiabilityMask` in `ExtInfo` to 3 bits so that it now holds all 4 cases of `DifferentiabilityKind`.
- Parse `@differentiable(reverse)` and `@differentiable(_forward)` declaration attributes and type attributes.
- Emit a warning for `@differentiable` without `reverse`.
- Emit an error for `@differentiable(_forward)`.
- Rename `@differentiable(linear)` to `@differentiable(_linear)`.
- Make `@differentiable(reverse)` type lowering go through today's `@differentiable` code path. We will specialize it to reverse-mode in a follow-up patch.
ABI:
- Add `Forward` and `Reverse` to `FunctionMetadataDifferentiabilityKind`.
- Extend `TargetFunctionTypeFlags` by 1 bit to store the highest bit of differentiability kind (linear). Note that there is a 2-bit gap in `DifferentiabilityMask` which is reserved for `AsyncMask` and `ConcurrentMask`; `AsyncMask` is ABI-stable so we cannot change that.
_Differentiation module:
- Replace all occurrences of `@differentiable` with `@differentiable(reverse)`.
- Delete `_transpose(of:)`.
Resolves rdar://69980056.
Enable `@differentiable` attribute on setters of properties and
subscripts in `Differentiable`-conforming types.
Add automatically-differentiated `@differentiable` setter test.
Resolves TF-1166.
A `@differentiable` function type require at least 1 differentiability parameter. This PR adds a diagnostic that rejects cases where all parameters are marked with `@noDerivative`. This fixes a compiler crasher.
```swift
test2.swift:3:24: error: '@differentiable' function type requires at least one differentiability parameter, i.e. a non-'@noDerivative' parameter whose type conforms to 'Differentiable'
let _: @differentiable (@noDerivative Float) -> Float = { _ in 0 }
^~~~~~~~~~~~~~~~~~~~~
test2.swift:4:32: error: '@differentiable' function type requires at least one differentiability parameter, i.e. a non-'@noDerivative' parameter whose type conforms to 'Differentiable' with its 'TangentVector' equal to itself
let _: @differentiable(linear) (@noDerivative Float, @noDerivative Int) -> Float = { _, _ in 0 }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Use the FullyQualified<Type> abstraction from the prior commit plus DescriptiveDeclKind to give a bit more information when issuing a missing member type diagnostic during type resolution.
