Instead, generate the type variable in ConstraintGenerator.
However, we only want to generate it if we're type checking
from inside TypeChecker::typeCheckCompletionSequence(), so
add an isActivated() flag to CodeCompletionExpr. If it is
not set, constraint generation will simply fail on an
expression containing a CodeCompletionExpr.
Given something like `max(1, 2)` inside a type that conforms to Sequence, this
allows the compiler to consider Swift.max as well as the two methods with that
name on Sequence.
When the operand of a collection upcast is a dictionary literal,
upcast the elements of the collection instead. This avoids going
through the dynamic-casting machinery.
When we form a collection upcast of an array literal, upcast the
individual elements directly so we avoid a call through the
runtime. This both improves code generation and sidesteps a regression
involving the inability to dynamically cast function types.
Fixes SR-7362 / rdar://problem/39218656.
We just needed to select the final type based on which branch of the
disjunction successfully type-checked the expression.
Fixes [SR-7208](https://bugs.swift.org/browse/SR-7208)
and rdar://problem/37159360.
Instead of passing the base expression of a member access to `getAccessSemanticsFromContext`, we now just pass a bool flag for whether this is a member access on the implicit 'self' declaration.
Currently we always directly access a member when mutating it in its own didSet/willSet observer (in order to prevent infinite recursion). However we also do this even when accessing the same member on a *different* instance.
This commit changes the behaviour such that only member accesses on the implicit 'self' declaration are accessed directly within that member's own willSet/didSet.
Note that this change has the potential to cause recursion in cases where it didn't previously, for example this will now infinitely recurse:
struct S {
var i = 0 {
didSet {
var s = self
s.i = 5
}
}
}
var s = S()
s.i = 2
I don't know how serious this impact is though.
Resolves SR-419.
We need to ensure that the conformance is fully reified during type checking since we will use it during SILGen for the keypath. Speculative fix for SR-7207.
Allow certain bindings and conversions involving non-escaping
function types to succeed in "diagnostic" mode to gather fixes
and diagnose such problems better, expecially related to
conversions to 'Any' and generic parameters.
Resolves: rdar://problem/38648760
Some of the expressions call into `typeCheckExpressionShallow` while trying to
apply solutions, we need to respect the fact that sub-expressions might be
already properly type-checked while propagating l-value access kind.
Resolves: rdar://problem/38309176
When performing a binding/assignment to a weak or unowned variable/property from an initialiser call, emit a warning that the instance will be immediately deallocated.
We were inserting function conversion expressions that were then
turned into forces of values in cases where we merely referenced
functions, but did not actually call them.
Fixes rdar://problem/37241550.
We were not handling IUO results of @optional protocol methods
properly, sometimes forcing the @optional requirement rather than the
result of the call.
Fixes rdar://problem/37240984.
* Implement the recently accepted SE-0195 proposal, which introduces "Dynamic
Member Lookup" Types. This is a dusted off and updated version of PR13361,
which switches from DynamicMemberLookupProtocol to @dynamicMemberLookup as
was requested by the final review decision. This also rebases it,
updates it for other changes in the compiler, fixes a bunch of bugs, and adds support for keypaths.
Thank you to @rudx and @DougGregor in particular for the helpful review comments and test cases!
This is useful for explicit casts and type expressions, where
type loc and expression types might be different, and allows
constraint solver to avoid setting opened types to expressions
which resolves multiple crashes.
Allow functions with type `(()) -> T` to be passed in places where we
expect `() -> T`, but only for -swift-version 4 (for -swift-version 3
this already works due to other horrible things in CSSimplify.cpp).
We need to look at how we can help migrate these cases to
-swift-version 5, but in the meantime, but that is something we can
consider separately.
