When realizing a type like Foo<A>.Bar, we have to account for the
possibility that Bar is defined in a constrained extension of Foo,
and has generic requirements beyond those that Foo itself places
on 'A'.
Previously we only handled this for types referenced from the
constraint system as part of openUnboundGenericType(), so we were
allowing invalid types through in type context.
Add the right checking to applyGenericArguments() to close the
hole. Note that the old code path still exists in the constraint
solver; it is used for member accesses on metatype bases only.
Fixes <https://bugs.swift.org/browse/SR-10466>.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
Do not offer a mutating fix-it if we have a mutating protocol requirement and we're assigning to it from an implicitly nonmutating setter inside a protocol extension
Instead of computing it from the extended type after deserialization --
which is tricky to do, due to potential presence of protocol
compositions -- we obtain the extended nominal directly.
Fixes SR-11227 and linked rdar://problem/53712389.
When there's a module with the same name as a type in a
different module, lookup will look into the type, not the module, when
resolving members. Until that behavior is fixed, add a note showing what
lookup was trying to look into, to make the behavior more clear.
Helps rdar://54770139
1. If this is a special name avoid printing it because
printing kind is sufficient;
2. If all of the labels match, print a full name;
3. If labels in different choices are different, it means
that we can only print a base name.
For multiple solutions with fixes for the same call, replace
`ambiguous reference` diagnostic with the one that explicitly
mentions that there are no exact matches, and provide partially
matched candidates as notes.
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.
