Disallow implicit conversion or arguments from Array, String, and
InOut (formed by &) to pointer types if the argument is for an
@autoclosure parameter.
These conversions were really only intended to be used for C/ObjC
interop, and in some contexts like autoclosures they are not safe.
Fixes: rdar://problem/31538995
This is modeled in constraint system in a way
that when member type is resolved by `resolveOverload`
it would take r-value type of the element at
specified index, but if it's a type variable it
could still be bound to l-value later, so r-value
result has to be enforced by coercion if necessary.
Resolves: rdar://problem/39931475
Rather than ASTContext-allocating ConcreteDeclRef’s storage when there is a
non-empty substitution map, put the SubstitutionMap directly in the
ConcreteDeclRef. Simplify the various interfaces along the way.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
This code dates back to the dark ages when forming substitutions
was something only the constraint solver could do.
Now that findNamedWitnessImpl() returns a ConcreteDeclRef instead
of a ValueDecl, we don't have to build a whole constraint system
and type check it just to form substitutions for the call.
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.
