Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
Both single- and multi-statement closures now use variable reference
collector to identify variables used in the interpolation body, which
means that it's not longer necessary to connect to the closure explicitly
(if interpolation is contained in one).
Since "tap" bodies are now type-checked together with the context,
it's imperative that the variable that represents an interpolation
never gets disconnected from its context in the constraint system,
otherwise it wouldn't be possible to determine types for the
references.
Generate a conjunction for each tap expression body as soon as it
gets a contextual type instead of separate post-factum type-checking
via `typeCheckTapBody`.
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.
As described in the issue #62922, the compiler should not allow to discard @noDerivative attribute and keep @differentiable. The patch adds a diagnostic for this case.
Resolves#62922.
As with the initial value of a property that is converted from a stored
property to a computed property by an accessor macro, remove
didSet/willSet. It is the macro's responsibility to incorporate their
code or diagnose them.
Fixes rdar://111101833.
If an accessor macro is placed on a computed property, then opts not to
produce a getter/setter, we would produce an error because the macro
didn't make the computed property... computed. Fix that; it's already
computed, and it's fine not to add accessors.
Fixes rdar://111586568.
@_implementationOnly was designed for use from resilient modules only,
using it from non-resilient modules in unsupported. This change adds a
warning about it.
If anyone hits this warning, they should either enable library-evolution
or consider adopting the new `internal import` when it is available as
it handles this scenario properly.
What leads to a crash: an @_implementationOnly import fully hides the
dependency from indirect clients. This can lead to the compiler being
unaware of some internal details of a non-resilient module when building
a client against it. In turn this may lead to run time crashes from
miscompilation.
In general one could still use @_implementationOnly in a non-resilient
modules as long as it's referenced only from function bodies. However,
references from even non-public properties does lead to important memory
layout information being hidden from clients of the module.
rdar://78129903
