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>.
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.
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.
The diagnostic change is harmless. The diagnostic that is no longer being
emitted was intended for multi-file conformance checking only, and we still
emit a diagnostic for the overall conformance failure with missing witnesses.
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.
If a generic parameter has both a class and protocol constraint,
walking up to the class's superclass would cause us to subsequently
ignore any initializer requirements in the protocol.
Fixes <https://bugs.swift.org/browse/SR-1663>, <rdar://problem/22722738>.
When performing a binding/assignment to a weak or unowned variable/property from an initialiser call, emit a warning that the instance will be immediately deallocated.
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.
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
Typealiases in protocol extensions can be used to satisfy
associated type requirements. However, when they don’t meet all
of the requirements placed on the associated type, fall back to
the normal inference path rather than failing outright.
Fixes SR-6609 / rdar://problem/36038033.
Introduce an ugly hack where a typealias in a protocol extension that
has the name `_Default_Foo` can be found by associated type inference for
an associated type named `Foo`, respecting the constrains of the protocol
extension in which that typealias resides.
When a protocol closes off an associated type by tying it to a concrete
type (e.g., via a same-type constraint), allow associated type inference
to use that information to infer the associated type rather than
requiring the user to restate the obvious.
Fixes SR-6640.
During associated type inference, also look for default associated type
witnesses from overridden associated types, so that one need not
redeclare default associated types at every level in a protocol hierarchy.
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.
Within the compiler, we use the term "layout constraint" for any
constraint that affects the layout of a type parameter that has that
constraint. However, the only user-visible constraint is "AnyObject",
and calling that a layout constraint is confusing. Drop the term
"layout" from diagnostics.
Fixes rdar://problem/35295372.
Associated type redeclarations occasionally occur to push around
associated type witness inference. Suppress the warning about redeclarations
that add no requirements (i.e., have neither an inheritance nor a
where clause).
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>.
As part of type witness inference, allow us to infer a generic parameter
as the type witness for an associated type, when the associated type has
the same name as the generic parameter.
We likely want the more-general rule that generic parameters are always
visible as members of their enclosing type, but I'll tackle that separately.
This works around an order dependency that affected the source
compatibility suite.
When an associated type declaration “overrides” (restates) an associated
type from a protocol it inherits, note that it overrides that declaration.
SourceKit now reports overrides of associated types.
If unqualified name lookup finds an associated type, but resolution to
the type witness fails, produce a diagnostic rather than silently
failing. Fixes the crash in SR-5825, SR-5881, and SR-5905.
It's conceivable that we could resolve this with suitably global
associated type inference... but that's far off and it's best not to
crash until then.
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
