SourceKit always sets it positively. This may lead to more aggressive fixits however
less informative messages. We currently use the flag only for filling protocol stubs.
This reverts part of #4038 which made the compiler consider it to be an `Explicit` conformance, breaking source code that was accepted in Swift 3.0 which declared a raw type as well as explicit conformance to `RawRepresentable` (reported as rdar://problem/30386658). While I'm here, a couple of spot fixes:
- Ensure an enum's raw value exprs are type-checked before checking conformances of any of its extensions, since the RawRepresentable conformance derivation will blow up if the raw value exprs haven't been checked. Fixes an order dependency issue if `extension Foo: RawRepresentable {}` gets checked before `enum Foo: Int { ... }`.
- Don't display the custom `enum_declares_rawrep_with_raw_type` diagnostic if the source location for the enum's inheritance clause is invalid, so that we don't emit a dislocated diagnostic.
Until recently we didn't allow nested generic types at all.
In Swift 3, generic typealiases were added, and we forgot to
guard against them in witness matching, leading to a crash if
a generic typealias witnesses an associated type requirement.
Now that nested generic nominals are allowed too, add a check.
The diagnostic is not very good, but I'll revisit this later.
This fixes a regression from the previous patch which got
rid of PrintOptions::StripDynamicSelf.
When printing protocol declarations with a BaseType set in
PrintOptions, we can end up with a DynamicSelfType wrapping
a non-class type, if the protocol requirement returned
Self.
Note that this changes the diagnostic for missing protocol
requirements slightly; we used to sometimes refer to 'Self'
even if the conforming type is not a class, which is not
accepted by the type checker anyway. I believe the new
diagnostics are more correct.
The @objc optional requirement near-miss heuristics were too
permissive, and could occasionally produce ridiculous results that
were nowhere close to a "near" miss. Make the diagnostics more
conservative, and fix an issue with an errant sentinel value.
Fixes rdar://problem/26380688.
An overriding declaration doesn't have a choice about its signature,
because the signature is dictated by the overridden
declaration. Therefore, don't produce a warning for it.
Fixes rdar://problem/28524237.
When @objc inference was extended to look at the conformances of
superclasses, the code that diagnosed near misses was not similarly
updated, so we could end up producing a near-miss diagnostic on a
declaration that was already a witness to another protocol. Use the
same witness-finding logic that we use for @objc inference so this
doesn't happen again.
Fixes the rest of rdar://problem/27348369
In most places where we were checking "is<ErrorType>()", we now mean
"any error occurred". The few exceptions are in associated type
inference, code completion, and expression diagnostics, where we might
still work with partial errors.
This was causing us to emit diagnostics talking about τ_m_n, which is
not helpful.
Now that generic function types print sanely, print them in a few
places where we were previously printing PolymorphicFunctionTypes.
When checking a conformance of a concrete type to a protocol, we
effectively checked the associated types twice -- once when
deriving them, and another time at the end, where we performed
a substitution of the protocol 'Self' type to the concrete type.
The latter checked superclass constraints, while the former did not.
However, this trick no longer works with minimized generic
signatures, because <P : Self> no longer has redundant requirements
for the associated types of 'P'.
Instead, check superclass constraints at the same time as checking
conformances.
* If current context is extension of non-final class, don't suggest stub
* If current context is extension of final class, insert 'convenience'
* If current context is direct definition of non-final class, insert 'required'
This fixes several issues:
- By default parent types of alias types are not printed which results in
- Erroneous fixits, for example when casting to 'Notification.Name' from a string, which ends up adding erroneous cast
as "Name(rawValue: ...)"
- Hard to understand types in code-completion results and diagnostics
- When printing with 'fully-qualified' option typealias types are printed erroneously like this "<PARENT>.Type.<TYPEALIAS>"
The change make typealias printing same as nominal types and addresses the above.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
To each note with a protocol requirement that is not met, a fixit is
added that inserts a stub for the requirement at the start of the
adoptee's declaration.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
This is a follow-up to the change that allowed one to omit @objc (or
the name in an @objc) when it can be inferred by matching a
requirement. There is no point in suggesting that one add @objc if it
will be inferred anyway, since it's just syntactic noise.
Use the diagnostics machinery of the protocol conformance checker to
say why each near-miss actually missed, e.g., a type conflict. This
gives better information regarding how to fix the actual problem. Yet
more QoI for rdar://problem/25159872.
The differences between Swift 2 and Swift 3 names can be very
significant, when the Swift 2 names have a lot of restated type
information. These differences end up disabling the near-miss
heuristics because the magnitude of the change is so high. Therefore,
apply the omit-needless-words heuristics to the potential witness and
the requirement before scoring them.
Should finish up rdar://problem/25159872 for real.
The Grand API Renaming tends to split long base names into a shorter
base name + first argument label. To account for this in near-miss
checking, consider the base name + first argument label as a unit.
It's a common mistake to mistype a declaration that is intended to
satisfy an optional requirement. In such "near misses", we want to
warn about the mistake and give the user options to either fix the
declaration or suppress the warning. Approach this problem be walking
over all of the members of each nominal type declaration or extension
therefore and looking to see if there are any members remaining that
(1) are similarly-named to an unfilfilled optional requirement of a
protocol whose conformance is attributed to that nominal type
declaration or extension,
(2) are not witnesses to another optional requirement,
(3) haven't explicitly suppressed the warning (e.g., by adding
explicit "private" or explicit "@nonobjc"), and
(4) have a useful suppression mechanism.
In addition to the suppression mechanisms described in (3), one can
suppress this warning by moving the declaration to an(other)
extension. This encourages a programming style where one breaks an
interface into extensions each implement conformance to one
protocol. Note that we encode the various cases where one cannot move
the declaration to another extension (e.g., one cannot move a
designated initializer or stored property out of a class declaration)
and suppress the warning when there's no way for the user to cope with
it.
Each warning produced by this diagnostic can have a bunch of notes on
it for various courses of action. For example:
t2.swift:7:14: warning: instance method 'doSomething(z:)' nearly
matches optional requirement 'doSomething(x:)' of protocol 'P1'
@objc func doSomething(z: Double) { }
^
t2.swift:7:14: note: rename to 'doSomething(x:)' to satisfy this
requirement
@objc func doSomething(z: Double) { }
^
x
t2.swift:7:14: note: move 'doSomething(z:)' to an extension to silence
this warning
@objc func doSomething(z: Double) { }
^
t2.swift:7:14: note: make 'doSomething(z:)' private to silence this
warning
@objc func doSomething(z: Double) { }
^
private
t2.swift:2:17: note: requirement 'doSomething(x:)' declared here
optional func doSomething(x: Int)
^
It's a *lot* of detail, but is intended to cover the various choices
available to the user: Fix-It to the names of the requirement (for
naming-related mistakes) or suppress via various mechanisms. Combining
notes means losing Fix-Its, while dropping notes can lead users to
non-optimal solutions.
This is more of rdar://problem/25159872.
When checking for permitted uses of Self in the input type of a
protocol requirement's function type, if the parameter itself was
a function we would recurse into its input, and reject all uses
of Self in the parameter type's result. This was the wrong way
around, and in fact we should recurse into the result.
Here is a test case that used to compile successfully and crash;
now it is rejected by the type checker:
protocol P {
func f(a: Self -> ())
}
protocol Q : P {
func g()
}
class C : P {
func f(a: C -> ()) { // should not be allowed to witness P.f
a(C())
}
}
class B : C, Q {
var x: Int = 17
func g() {
print(x)
}
}
func f<T : Q>(t: T) {
// T == B here
// t.f has type <T : Q> (T -> ()) -> ()
t.f({ $0.g() }) // but at runtime, $0 is a C not a B
}
f(B())
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
As of r31224, we tried to suppress redundant protocol-conformance
diagnostics for witnesses that look like they could have matched
something in an unconstrained protocol extension. However, this was
allowing ill-formed conformances to be accepted, causing a crash in
the AST verifier. Fixes rdar://problem/23033862.
Swift SVN r32671
Cleans up AST printing somewhat as well as providing slightly better
type-to-declaration mappings for annotated AST printing and indexing.
Swift SVN r32420
(Specifically, unconstrained extensions.)
This removes the problem where trying to conform to a protocol spits out
a dozen errors about missing requirements in a base protocol, but eleven
of them have a sensible default implementation with no constraints. This
is "P6" in the test cases; the others all passed before.
There's still plenty more work in this space. In particular, if an
associated type is missing we just give up rather than encouraging people
to provide the members it would be inferred from.
Swift SVN r31224
