Within the compiler, we use the term "layout constraint" for any
constraint that affects the layout of a type parameter that has that
constraint. However, the only user-visible constraint is "AnyObject",
and calling that a layout constraint is confusing. Drop the term
"layout" from diagnostics.
Fixes rdar://problem/35295372.
Because of the way we modeled the 'class' constraint in Swift <= 4, we
allowed both 'class' and 'AnyObject' to be specified on a protocol,
even in Swift 4 when they became equivalent. Recent refactoring
started rejecting such code; allow it now.
Fixes rdar://problem/34496151.
This eliminates the need for an ugly and incomplete hack to suppress
noescape inference for setter arguments. It also means we stop emitting
redundant diagnostics for problems in storage types.
Swift 3 allowed a requirement to be satisfied by an unavailable
witness, which doesn't make sense. We've been warning about it in
Swift 3 for a while; make it an error in Swift 4.
When trying to diagnose problems related to calls where
function is represented by a member of nominal type let's
attempt to be more cautious while type-checking function
expression without it's arguments, because it could produce
unrelated diagnostics.
Resolves: rdar://problem/32551313, rdar://problem/28456467, rdar://problem/31671195
This makes it a lot easier to diagnose contextual mismatch related
to arguments used by the call without relying on the type of the
function expression which is not always available.
Swift 3 had a type soundness hole in protocol conformance checking
where the requirement contained an "== Self" constraint and the
witness was a member of a non-final class. We previously closed the
type soundness hole in PR #9830, but left it as a warning in Swift 3
compatibility mode.
Escalate that warning to an error. The optimizers break due to this
type soundness hole, and of course it can lead to other runtime
breakage because it violates the type system.
Fixes rdar://problem/28601761.
Restore the old Swift 3 behavior for source compatibility reasons:
- Unqualified lookup finds static properties (but not static methods)
first, then global members.
- Qualified lookup into 'self' is still supported.
There's no change in Swift 4 mode, where the newer more correct
behavior is enabled.
Fixes <rdar://problem/32570766>.
Enum elements have to be treated the same way as regular functions
when passed as values, which means labels have to be stripped from
their argument types.
Resolves: rdar://problem/32300339.
If there are parameters missing in the closure declaration and
all of the present ones are anonymous let's emit a fix it suggesting
missing parameters.
Resolves: rdar://problem/32301091
Protocol requirements involving same-type-to-Self constraints cannot
be witnessed by declarations in non-final classes that have the same
form of same-type requirement to the corresponding class type, because
it creates a soundness hole with subclasses:
protocol Q {
func foo<T: P>(_: T, _: T.T) where T.T == Self
}
class C: Q {
func foo<T: P>(_: T, _: C) where T.T == C {}
}
class D: C {
// in D, T.T == D does not hold
}
Warn about this in Swift 3 compatibility mode, error on it in Swift 4
mode. When possible, provide a note + Fix-It suggesting that the
same-type constraint might be weakened to a superclass constraint
(which works with subclassing).
Fixes rdar://problem/30398503.
In Swift 3, we required that '.self' be specified on TypeExprs
and DeclRefExprs that reference types.
However, types referenced as member lookups, such as 'Foo.Bar',
did not get this treatment, and '.self' was not required.
Fix this by emitting warnings in the cases that Swift 3 did not
diagnose, and producing errors in Swift 4 mode where we want
strict enforcement.
Properly diagnose cases of function/subscript argument tuple
structuring/destructuring related by not limited to SE-0110.
Resolves: rdar://problem/31973368
Fix a silly gap in my fix for rdar://problem/31104415, where imported
types that gain conformances through their overlays were still getting
errors. Fixes SR-4820 / rdar://problem/32134724.
Deserializing a witness record in a conformance may fail if either of the requirement or witness changed name or type, most likely due to SDK modernization changes across Swift versions. When this happens, leave an opaque placeholder in the conformance to indicate that the witness exists but we don't get to see it. For expedience, right now this just witnesses the requirement to itself, so that code in the type checker or elsewhere that tries to ad-hoc devirtualize references to the requirement just gets the requirement back. Arguably, we shouldn't include the witness at all in imported conformances, since they should be an implementation detail, but that's a bigger, riskier change. This patch as is should be enough to address rdar://problem/31185053.
While diagnosing index expression associated with subscript call
`validateContextualType` didn't look through TupleType to identify
potential nullability of the contextual type related to generic
parameters.
Resolves: rdar://problem/31724211
Swift 3 allowed a class to explicitly conform to AnyObject, although
it was meaningless. Recent AnyObject-related changes started rejecting
such conformances as ill-formed; allow them with a warning + Fix-It in
Swift 3 compatibility mode.
When an extension introduces a conformance that already exists, the
type checker will reject the conformance and then ignore it. In cases
where the original conformance is in the same module as the type or
protocol (but the new, redundant conformance is in some other module),
downgrade this error to a warning. This helps with library-evolution
cases where a library omitted a particular conformance for one of its
own types/protocols in a previous version, then introduces it in a new
version.
The specific driver for this is the conformance of String to
Collection, which affects source compatibility. Fixes
rdar://problem/31104415.
(in Swift 4 mode)
There are a lot of other things that overload ranking does *not* take
into account, and I intend to file a more general bug about that, but
this should resolve some of the most egregious ambiguities with Swift
3's import rules (SE-0005, particularly "omit needless words" and
adding default arguments).
Finishes rdar://problem/25607552.
Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
This snippet type checks in Swift 4 mode, but not in Swift 3.
It used to work in Swift 3.0, so something broke when we
implemented SE-0110 and redid the Swift 3 mode emulation.
If the -enable-experimental-subclass-existentials staging flag
is on, resolveType() now allows protocol compositions to contain
class types. It also diagnoses if a composition has more than one
superclass requirement.
Also, change diagnostics that talked about 'protocol composition'
to 'protocol-constrained type'.
Since such types can now contain a superclass constraint, it's not
correct to call them protocol composition.
"Protocol-constrained type" isn't quite accurate either because
'Any' has no protocols, and 'AnyObject' will have no protocols but
a general class constraint; but those are edge cases which won't
come up in these diagnostics.
Fixes:
https://bugs.swift.org/browse/SR-3455https://bugs.swift.org/browse/SR-3663https://bugs.swift.org/browse/SR-4032https://bugs.swift.org/browse/SR-4031
Now, compilation conditions are validated at first, then evaluated. Also,
in non-Swift3 mode, '&&' now has higher precedence than '||'.
'A || B && C || D' are evaluated as 'A || (B && C) || D'.
Swift3 source breaking changes:
* [SR-3663] This used to be accepted and evaluate to 'true' because of short
circuit without any validation.
#if true || true * 12 = try Anything is OK?
print("foo")
#endif
In this change, remaining expressions are properly validated and
diagnosed if it's invalid.
* [SR-4031] Compound name references are now diagnosed as errors.
e.g. `#if os(foo:bar:)(macOS)` or `#if FLAG(x:y:)`
Swift3 compatibility:
* [SR-3663] The precedence of '||' and '&&' are still the same and the
following code evaluates to 'true'.
#if false || true && false
print("foo")
#endif
When this was migrated over to the awesome new special representation
of type(of:) the argument coercion didn’t come with it. The missing
load expression caused any l-value run through type(of:) to crash in the
verifier.
