Perhaps we should refactor everything so that extensions
that are not at the top-level are still bound and type
checked normally. However that requires a bit of work, so
keep playing wack-a-mole for now to handle these invalid
states when they come up.
However while we're at it, make the code a little better
by removing a bogus diagnostic path that was not used.
Fixes <rdar://problem/45290211>, <https://bugs.swift.org/browse/SR-9009>.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
If all of the solutions in the set have a single fix, which points
to the common anchor, attempt to diagnose the failure as an
ambiguity with a list of candidates and their related problems as notes.
Having richer message like that helps to understand why something is
ambiguous e.g. if there are two overloads, one requires conformance
to some protocol and another has a same-type requirement on some type,
but neither matched exactly, having both candidates in the diagnostic
message with associated errors, instead of simplify pointing to related
declarations, helps tremendously.
In-place initialization means the class has a symbol we can reference
from the category, so there's nothing to do on the IRGen side.
For JIT mode, we just need to realize the class metadata by calling an
accessor instead of directly referencing the symbol though.
This patch adds warning for redundant access-level modifiers
used in an extension. It also refines the diagnostics of
access_control_ext_member_more issues, in case the fixit
could suggest redundant modifiers.
Resolves: SR-8453.
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
Use ExtensionDecl::getExtendedNominal() to wire up extensions to their
nominal types early in type checking (the bindExtensions()) operation,
rather than going through type validation to do so.
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
Note that you can still run into problems because of over-eager
declaration validation triggered by resolving nested types.
However, that's a separate problem.
Fixes <https://bugs.swift.org/browse/SR-631> and
<rdar://problem/20535574>.
Replacing invalid Self requirements with the context type only produces
an unnecessary and somewhat misleading error, stating that the replaced
type isn't a valid parameter or associated type. We don't want that when
the 'Self can't be used...' error is already being shown.
If there was any requirements in the @objc protocol, the user got an error in
some form (a complaint about those requirements), but giving the direct error is
better, and handles @objc protocol with no requirements.
Also, fix a hole in that existing @objc method check: in `class Outer<T> { class
Inner {} }`, Inner should be considered generic, but the loop that was checking
for this didn't consider it.
Fixes https://bugs.swift.org/browse/SR-7370 and rdar://problem/39239512.
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
IsFirstPass is going away soon, but in the meantime, the next
patch regresses matters slightly and causes us to emit
duplicate diagnostics in more cases, so let's fix it.
There are a number of things that can only be written within the main
type definition (e.g., required initializers, stored properties),
making it far more likely that we'll get false positives from the
newly-introduced "near-miss" warnings for protocol
conformances. Moreover, sometimes a number of protocol conformances
are placed on the main type definition, increasing the potential for
false positives.
Suppress near-miss warnings for potential candidates when the protocol
conformance is stated on the main type definition itself. Therefore,
we only perform near-miss checking of non-@objc requirements when the
conformance itself was declared on an extension, which is roughly the
development style that near-miss warnings favor.
Fixes rdar://problem/37283860.
This is a corner case but would previously lead to a compiler crash
or miscompile.
Fixes <rdar://problem/21991470>, <https://bugs.swift.org/browse/SR-5022>.
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
When a particular nominal type or extension thereof declares conformance
to a protocol, check whether that type or extension contains any members
that *nearly* match a defaulted requirement (i.e., a requirement that
is satisfied by something in a protocol extension), but didn’t match
for some reason and weren’t used to satisfy any other requirement of
that protocol. It’s intended to catch subtle mistakes where a default
gets picked instead of the intended member.
This is a generalization of the code we’ve had for @objc optional
requirements for a long time.
Fixes rdar://problem/24714887.
Some messages said 'typealias' and others said 'type alias'.
Change everything to use 'type alias' consistently (except
when it's talking about the keyword itself).
A protocol extension can add additional generic constraints on
'Self' or associated types thereof. In particular, 'Self' itself
can have a superclass constraint placed on it.
There were a couple of problems with this corner case:
- Type aliases defined in protocols that 'Self' conforms to _as a
concrete type_ to were not handled properly, triggering an assertion.
For example,
protocol P { typealias T = ... }
class C : P {}
protocol Q {}
extension Q where Self : C { ... T ... }
The conformance o P comes from the 'Self : C' constraint.
- If the type was found in a superclass of 'Self', we used the wrong
base type for the substitution.
For example,
protocol P {}
class C<T> { typealias A = T }
class D : C<Int> {}
extension P where Self : D { ... A ... }
The substituted type of 'A' should be computed with a self type
of C<Int> here.
Also, take another stab at cleaning up the mess that is
resolveTypeInContext() and related bits of code.
As we've done with layout requirements, introduce a new entry point
(addTypeRequirement) that handles unresolved type requirements of the
form `T: U`, resolves the types, and then can
1. Diagnose any immediate problems with the types,
2. Delay the type requirement if one of the types cannot be resolved,
or
3. Break it into one or more "direct" requirements.
This allows us to clean up and centralize a bunch of checking that was
scattered/duplicated across the GSB and type checker.
