That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
We don't allow things like
extension Type: P where Param: P {}
extension Type: P where Param: Q {}
or
extension Type: P where Param == Int {}
extension Type: P where Param == Float {}
or
extension Type: P where Param: P {}
extension Type: P where Param == SomethingThatIsntP {}
and the default error message "redundant conformance" message doesn't convey
this very well.
Fixes rdar://problem/36262409.
The fix for <https://bugs.swift.org/browse/SR-617> introduced
a new kind of requirement environment where 'Self' remains a
generic parameter, but receives a class constraint, instead of
becoming fully concrete.
As before, we would form the synthetic signature by taking
the generic signature of the requirement, and substituting it
the new 'Self' type.
However, whereas previously the 'Self' type was always concrete
and any DependentMemberTypes in the requirement's signature
would become concrete type references, with a class-constrained
'Self' the DependentMemberTypes remain.
Apparently, the GSB cannot handle DependentMemberTypes where
the base is class-constrained.
Work around this by ensuring that we add a conformance constraint
for the 'Self' parameter to the protocol in question, which
allows the DependentMemberTypes to be correctly resolves once
the conformance is made concrete by a superclass constraint.
The FIXME comment being removed here references crashes which
no longer seem to reproduce, so I'm assuming some underlying
GSB issues got fixed and the FIXME is clearly no longer necessary.
However, I still consider this fix somewhat unsatisfying, because
it is not clear if there's some deeper flaw in how the GSB
models superclass constraints. It might resurface again in the
future.
Fixes <rdar://problem/39419121>, <https://bugs.swift.org/browse/SR-7428>.
A protocol extension of a private protocol can define internal
or public members. We should not be able to find these members
from another file or module if an internal or public type
conforms to the protocol.
Fixes <rdar://problem/21380336>.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
Extend protocol conformance checking to allow a requirement with an
escaping parameter (of function type) to be satisfied by a witness
with a corresponding non-escaping parameter. This limited form of
covariance was already supported by SILGen and is needed to address
the source-compatibility "regression" introduced by inferring escaping
function types for associated type witnesses. It's also obviously a
good idea :)
Fixes rdar://problem/35297911.
When inferring an associated type witness by matching a function signature,
adjust non-escaping function types to escaping function types, because only
escaping function types could be written as explicit witnesses and
non-escaping function types are not permitted outside of function
parameters.
Addresses the first part of rdar://problem/35297911, eliminating the
type-soundness issue.
Extend protocol conformance checking to allow a requirement with an
escaping parameter (of function type) to be satisfied by a witness
with a corresponding non-escaping parameter. This limited form of
covariance was already supported by SILGen and is needed to address
the source-compatibility "regression" introduced by inferring escaping
function types for associated type witnesses. It's also obviously a
good idea :)
Fixes rdar://problem/35297911.
When inferring an associated type witness by matching a function signature,
adjust non-escaping function types to escaping function types, because only
escaping function types could be written as explicit witnesses and
non-escaping function types are not permitted outside of function
parameters.
Addresses the first part of rdar://problem/35297911, eliminating the
type-soundness issue.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
Move associated type inference into its own class, to make this
code easier to understand/maintain/improve. Minor diagnostics changes
because we're properly passing uninference associated type declarations
to the "group" checker.
We allow definitions like this:
struct G<T> {}
typealias A = G
As a shorthand for
typealias A<T> = G<T>
A typealias like this cannot satisfy an associated type requirement
for the same reason that a generic typealias cannot satisfy an
associated type requirement, which was already handled.
Previously this would crash in the type checker or in IRGen.
This fixes a weird regression in a fixed compiler crasher from the
next patch.
If a class was introduced in an OS newer than the deployment target,
suppress the inference of @_staticInitializeObjCMetadata, because
the resulting eager initialization will crash when run on older OS's.
This is a stop-gap solution; we want the eager initialization code to
check availability before registering the class, but that requires more
effort.
Fixes the main part of SR-6203 / rdar://problem/35161939.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Replace a where Type-pointer-equality check with what it intended,
i.e., match up ParenTypes at the top level and perform a deeper
equality comparison of the underlying types.
Fixes SR-5166 / rdar://problem/32666189.
This time, the warnings only fire when the class in question directly
conforms to NSCoding. This avoids warning on cases where the user has
subclassed something like, oh, UIViewController, and has no intention
of writing it to a persistent file.
This also removes the warning for generic classes that conform to
NSCoding, for simplicity's sake. That means
'@NSKeyedArchiverEncodeNonGenericSubclassesOnly' is also being
removed.
Actually archiving a class with an unstable mangled name is still
considered problematic, but the compiler shouldn't emit diagnostics
unless it can be sure they are relevant.
rdar://problem/32314195
This is accomplished by recognizing this specific situation and
replacing the 'objc' attribute with a hidden '_objcRuntimeName'
attribute. This /only/ applies to classes that are themselves
non-generic (including any enclosing generic context) but that have
generic ancestry, and thus cannot be exposed directly to Objective-C.
This commit also eliminates '@NSKeyedArchiverClassName'. It was
decided that the distinction between '@NSKeyedArchiverClassName' and
'@objc' was too subtle to be worth explaining to developers, and that
any case where you'd use '@NSKeyedArchiverClassName' was already a
place where the ObjC name wasn't visible at compile time.
This commit does not update diagnostics to reflect this change; we're
going to change them anyway.
rdar://problem/32414557
None of the clients of this care about distinguishing between immediate
failures in getWitnessType() vs. earlier errors that result in
getWitnessType() returning ErrorType, so simplify the interface by
having it always return Type() if there is a problem.
Update the clients that were not already checking for null result to do
so.
Fixes rdar://problem/32215763.
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.
Adoption so far shows that the criteria we set up here are too broad.
This is particularly problematic for subclasses of NS/UIView and the
like that might never be encoded at all.
rdar://problem/32306355
