The Swift class model does not support overriding declarations where either
the overridden declaration or the overriding declaration are in an extension.
However, the Objective-C class model does, so marking the declaration as
@objc (when possible) will work around the limitation.
Customize the "cannot override declaration in extension" diagnostic to
suggest adding @objc to the overridden declaration in cases where
@objc is permitted. Fixes SR-6512 / rdar://problem/35787914.
Follow-up for 7c707ce97c. Without this, the declaration would be
accepted, but any uses of the overridden property would be treated as
ambiguous because the property wouldn't really be marked as an
override.
rdar://problem/35900345
Previous versions of Swift accidentally treated lazy properties as
computed properties because of how they were implemented. Now that we
check this correctly, we've broken source compatibility. Downgrade the
error to a warning in this case.
(Arguably we could /allow/ overriding with a stored property. The
original concerns were that you could accidentally end up with extra
storage you didn't need, and that observing accessors would behave
differently based on whether or not the property was overriding. But
there's at least no ambiguity for 'lazy', which can't have observing
accessors today.)
rdar://problem/35870371
Fix problem related to Swift 3 mode (with assertions),
since Swift 3 mode allows passing arguments with extra parens
to parameters which don't expect them, it should be supported
by "deep equality" types e.g. Optional<T>:
```swift
func foo(_: (() -> Void)?) {}
func bar() -> ((()) -> Void)? { return nil }
foo(bar) // This expression should compile in Swift 3 mode
```
Resolves: rdar://problem/35198459
The previous code was too clever in trying to avoid work and missed
the fact that ClassDecl::getSuperclass produces an interface type but
the types in the inheritance clause are contextual types.
This actually successfully built:
- in non-WMO builds with a public subclass and an internal base class,
because the internal class symbol wouldn't get stripped out.
- in WMO builds with an internal subclass and a private base class,
because 'private' has no distinction at the linkage level for a WMO
build.
However, it's highly likely that trying to import a library containing
such types would result in instability (read: compiler and debugger
crashes), and it's clearly a mistake to allow this. (If you can't show
your superclass to a user in a library's generated interface,
something's definitely gone wrong.)
https://bugs.swift.org/browse/SR-6206
In Swift 4, properties declared with a sugared Optional type,
like Int?, have a default value of nil. This can be observed
in two ways:
- Classes and structs get an implicit no-argument initializer
- Designated initializers don't have to initialize this property
Note that this did not apply in general to properties where
the type was spelled explicitly as Optional<Int>, etc, mostly
because of implementation restrictions -- when we check if a
type has implicit initializers, we have not realized types for
all stored property members yet, and doing so is not really
possible without the iterative decl checker.
However, in some cases, we *did* perform default initialization
for Optional<Int>, because of some code duplication and
divergent code paths.
A recent refactoring cleaned up some of the mess in this area,
but accidentally broke source compatibility with code that
relied on the broken Optional<Int> case.
Fix this by simulating the old behavior in -swift-version 4,
and preserving the more correct behavior in -swift-version 5.
Fixes <rdar://problem/35319847>.
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.
