Unless -enable-resilient-objc-class-stubs is passed in, these cases
are not supported, so now we diagnose them instead of asserting or
failing to link.
Note the behavior change here; classes with resilient ancestry were
previously isObjC(). However this is wrong since isObjC() means
"statically visible to Objective-C via the generated header".
After this patch, isObjC() only returns true for a class with resilient
ancestry if -enable-resilient-objc-class-stubs is passed in.
When a (non-generic) typealias refers to a specialization of a generic
type, e.g.
```swift
typealias simd_float3 = SIMD3<Float>
```
treat an extension of the typealias as an extension of the underlying
type with same-type constraints between the generic parameters and the
specific arguments, e.g.,
```swift
extension simd_float3 { }
```
is treated as
```swift
extension SIMD where Scalar == Float { }
```
This addresses a source-compatibility problem with SE-0229, where
existing types such as simd3_float (which were separate structs)
became specializations of a generic SIMD type.
Fixes rdar://problem/46604664 and rdar://problem/46604370.
Referring to a generic type without arguments inside the definition
of the type itself or an extension thereof is a shorthand for
forwarding the arguments from context:
struct Generic<T> {}
extension Generic {
func makeOne() -> Generic // same as -> Generic<T>
}
However this didn't work if the type was replaced by a typealias:
struct OldGeneric<T> {}
typealias Generic<T> = OldGeneric<T>
extension Generic {
func makeOne() -> OldGeneric // OK
func makeOne() -> Generic // error
}
Add a hack for making this work so that we better cope with the
renaming of DictionaryLiteral to KeyValuePairs in Swift 5.0.
Fixes <rdar://problem/43955962>.
Otherwise, we crash later in code that assumes the presence of a
generic parameter list implies the presence of a generic signature
(and vice versa).
Fixes <rdar://problem/46604393>.
The attempt to short-circuit wiring up generic parameters of a context
didn’t work when one of the inner types didn’t itself have generic
parameters. Make sure we still wire up generic parameters in this case.
Fixes a crasher encountered while investigating rdar://problem/43406595.
* Emit a warning diagnostic if an extension contains a redundant requirement
* Updates diagnostic message and checks if the extension type is a protocol
* Updates indentation and extracts self type
* [ast] Updates diagnostic message
* [ast] fix indentation
* [ast] Change ':' to 'to' in 'protocol_extension_redundant_requirement'
* [sema] Adds protocol extension redundant requirement check
Moved from TypeCheckRequests to TypeCheckGeneric
* [ast] fix some crashes related to null ptrs, check self type before emitting a diagnostic, update tests
* [ast] renames 'owner' to 'ext'
* [sema] fix style
* [test] Add another test case for redundant requirement
Co-Authored-By: theblixguy <suyashsrijan@outlook.com>
* [test] fix failing test
The test was failing because A has already been declared as a typealias.
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.
