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
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.
* [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
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
Currently `simplifyAppliedOverloads` depends on
the order in which constraints are simplified,
specifically that a lookup constraint for a
function gets simplified before the applicable
function constraint. This happens to work out
just fine today with the order in which we
re-activate constraints, but I'm planning on
changing that order.
This commit changes the logic such that it it's no
longer affected by the order in which constraints
are simplified. We'll now run it when either an
applicable function constraint is added, or a new
bind overload disjunction is added. This also
means we no longer need to run it potentially
multiple times when simplifying the applicable fn.
- In `simplifyConformsToConstraint`, pass the LHS
type regardless of whether it is a type variable.
- Add the `choiceImpact` onto the impact for
adding a stdlib conformance.
- Treat Any and AnyObject as standard library
types.
Previously we could skip default literal or
supertype bindings if we had already found a solution
with fixes, which could lead us to miss bindings
that produce better diagnostics.
Tweak the logic such that we continue exploring if
we're in diagnostic mode.
Resolves SR-12399.
* [Typechecker] Allow enum cases without payload to witness a static get-only property with Self type protocol requirement
* [SIL] Add support for payload cases as well
* [SILGen] Clean up comment
* [Typechecker] Re-enable some previously disabled witness matching code
Also properly handle the matching in some cases
* [Test] Update typechecker tests with payload enum test cases
* [Test] Update SILGen test
* [SIL] Add two FIXME's to address soon
* [SIL] Emit the enum case constructor unconditionally when an enum case is used as a witness
Also, tweak SILDeclRef::getLinkage to update the 'limit' to 'OnDemand' if we have an enum declaration
* [SILGen] Properly handle a enum witness in addMethodImplementation
Also remove a FIXME and code added to workaround the original bug
* [TBDGen] Handle enum case witness
* [Typechecker] Fix conflicts
* [Test] Fix tests
* [AST] Fix indentation in diagnostics def file
The `@transpose` attribute registers a function as the transpose of another
function-like declaration: a `func`, `init`, `subscript`, or `var` computed
property declaration.
The `@transpose` attribute also has an optional `wrt:` clause specifying the
linearity parameters, i.e. the parameters that are transposed with respect to.
The linearity parameters must conform to the `Differentiable` protocol and
satisfy `Self == TangentVector`.
If the `wrt:` clause is unspecified, the linearity parameters are inferred to be
all parameters that conform to `Differentiable` and that satisfy
`Self == TangentVector`.
`@transpose` attribute type-checking verifies that the type of the transpose
function declaration is consistent with the type of the referenced original
declaration and the linearity parameters.
Resolves TF-830.
Switch the direct operator lookup logic over to
querying the SourceLookupCache, then switch the
main operator lookup logic over to calling the
direct lookup logic rather than querying the
operator maps on the SourceFile.
This then allows us to remove the SourceFile
operator maps, in addition to the logic from
NameBinding that populated them. This requires
redeclaration checking to be implemented
separately.
Finally, to compensate for the caching that the old
operator maps were providing for imported results,
turn the operator lookup requests into cached
requests.
Serialize derivative function configurations per module.
`@differentiable` and `@derivative` attributes register derivatives for
`AbstractFunctionDecl`s for a particular "derivative function configuration":
parameter indices and dervative generic signature.
To find `@derivative` functions registered in other Swift modules, derivative
function configurations must be serialized per module. When configurations for
a `AbstractFunctionDecl` are requested, all configurations from imported
modules are deserialized. This module serialization technique has precedent: it
is used for protocol conformances (e.g. extension declarations for a nominal
type) and Obj-C members for a class type.
Add `AbstractFunctionDecl::getDerivativeFunctionConfigurations` entry point
for accessing derivative function configurations.
In the differentiation transform: use
`AbstractFunctionDecl::getDerivativeFunctionConfigurations` to implement
`findMinimalDerivativeConfiguration` for canonical derivative function
configuration lookup, replacing `getMinimalASTDifferentiableAttr`.
Resolves TF-1100.
Add `AdditiveArithmetic` derived conformances for structs and classes, gated by
the `-enable-experimental-differentiable-programming` flag.
Structs and classes whose stored properties all conform to `Differentiable` can
derive `Differentiable`:
- `associatedtype TangentVector: Differentiable & AdditiveArithmetic`
- Member `TangentVector` structs are synthesized whose stored properties are
all `var` stored properties that conform to `Differentiable` and that are
not `@noDerivative`.
- `mutating func move(along: TangentVector)`
The `@noDerivative` attribute may be declared on stored properties to opt out of
inclusion in synthesized `TangentVector` structs.
Some stored properties cannot be used in `TangentVector` struct synthesis and
are implicitly marked as `@noDerivative`, with a warning:
- `let` stored properties.
- These cannot be updated by `mutating func move(along: TangentVector)`.
- Non-`Differentiable`-conforming stored properties.
`@noDerivative` also implies `@_semantics("autodiff.nonvarying")`, which is
relevant for differentiable activity analysis.
Add type-checking and SILGen tests.
Resolves TF-845.
Add the `@differentiable` function conversion pipeline:
- New expressions that convert between `@differentiable`,
`@differentiable(linear)`, and non-`@differentiable` functions:
- `DifferentiableFunction`
- `LinearFunction`
- `DifferentiableFunctionExtractOriginal`
- `LinearFunctionExtractOriginal`
- `LinearToDifferentiableFunction`
- All the AST handling (e.g. printing) necessary for those expressions.
- SILGen for those expressions.
- CSApply code that inserts these expressions to implicitly convert between
the various function types.
- Sema tests for the implicit conversions.
- SILGen tests for the SILGen of these expressions.
Resolves TF-833.
Use `TypeChecker::checkDeclarationAvailability` instead of `isDeclAvailable`,
that is a proper API endpoint which does flag checking before calling
`isDeclAvailable` internally.
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.
Introduce evaluator::SideEffect, the type of a request that performs
some operation solely to execute its side effects. Thankfully, there are
precious few requests that need to use this type in practice, but it's
good to call them out explicitly so we can get around to making them
behave much more functionally in the future.
Checking for `-disable-availability-checking` in
`ConstraintSystem::isDeclUnavailable` caused a regression with
obsolete/introduced checking. Let's rely on
`DeclAttributes::isUnavailable` and `TypeChecker::isDeclAvailable`
to do the right thing instead.
Resolves: rdar://problem/60898369
Property wrappers are allowed to infer the type of a variable, but this
only worked when the property wrapper was provided with an explicit
initialization, e.g.,
@WrapsAnInt() var x // infers type Int from WrapsAnInt.wrappedValue
However, when default initialization is supported by the property wrapper,
dropping the parentheses would produce an error about the missing type
annotation
@WrapsAnInt var x
Make this second case behave like the first, so that default initialization
works consistently with the explicitly-specified version.
Fixes rdar://problem/59471019.
Add a request to lookup all implied conformances for use while
typechecking the primary. This provides a cache-point for
evaluator-based dependency tracking.
