When checking whether a particular protocol conformance satisfies all of
the protocol's requirements, we were suppressing substitution failures.
In some cases, this would mean that we marked a conformance "invalid"
without ever emitting a diagnostic, which would lead to downstream crashes.
Instead, treat substitution failures somewhat more lazily. If we encounter
one while performing the checking, put the conformance into a "delayed" list
rather than failing immediately. Teach the top-level type checking
loop to re-check these conformances, emitting a diagnostic if they
fail the second time around.
Fixes rdar://problem/35082483 and likely other issues that slipped
through the type checker or blew up in unpredictable ways.
Commit 53754a7a69 added a module pass that serializes the entire module.
Part of that pass is a method called removeSerializedFlagFromAllFunctions that removes the serialized flag from all functions within the module, which allows for more optimizations and for a better dead function elimination.
The problem is that this might break the Devirtualizer: If we run Devirtualization after “SerializeSILPass”, and we do LinkAll after Devirtualizing a function, SIL Verifier will fail: a public_external [serialized] function might be calling a [serialized] function for which we removed the [serialized] flag and added said flag to the module itself.
The verifier thinks that a function_ref inside fragile function is referencing private or hidden symbol.
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
While trying to diagnose a problem related to contextual result type
of the trailing closure, don't assume that declaration context is properly
set, instead directly set it to correct one before running type-check.
Resolves: rdar://problem/35699666
The enclosing conformance-lookup operation can fail (i.e., it returns
Optional), but the nested call was force-unwrapping the optional from
an inner call for no particular reason. Stop doing that, which fixes
SR-6466.
Note that the offending code is still something that should go away in
time, so this is merely polishing the band-aid to avoid a crash that
occurs often with conditional conformances.
When we substitute into an inherited conformance, make sure that we
follow the superclass chain from the new conforming type up to the
matching superclass *before* doing the substitution.
Fixes rdar://problem/35632543.
Fixes a former crasher that included well-formed code that was rejected
by my previous refactoring. Said crasher now passes, and IRGen's properly
as well. Also, account for three more fixed crashers.
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 various _*Indexable protocols only exist to work around the lack of
recursive protocol constraints. Eliminate all of the *_Indexable protocols,
collapsing their requirements into the corresponding Collection protocol
(e.g., _MutableIndexable —> Collection).
This introduces a number of extraneous requirements into the various
Collection protocols to work around bugs in associated type
inference. Specifically, to work around the lack of "global" inference
of associated type witnesses. These hacks were implicitly present in
the *Indexable protocols; I've made marked them as ABI FIXMEs here so
we can remove them when associated type inference improves.
Fixes rdar://problem/21935030 and a number of ABI FIXMEs in the library.
CSDiag was misinterpreting the result of checkGenericArguments().
A result of SubstitutionFailure does not mean a diagnostic was
emitted, only a result of Failure means that. This fixes a case
where we did not emit a diagnostic, result in a crash on invalid.
The diagnostic is still poor, but that's better than crashing.
Fixes <https://bugs.swift.org/browse/SR-5932>,
<rdar://problem/34522739>.
We are currently in process of removing `InOutType`
so `VarDecl::get{Interface}Type` is going to wrap base
type into `InOutType` if its flag indicates that it's
an `inout` parameter declaration. But such type can't
be restored directly using `VarDecl::set{Interface}Type`
caller needs additional logic to extract base type.
Resolves: rdar://problem/33613329
Arguments and parameters are not guaranteed to line-up perfectly,
because failure diagnostics sometimes has to match one argument
to different "candidate" parameters to see which one is closer,
so let's teach `computeDefaultMap` to respect that.
Resolves: rdar://problem/33433087.
When we detect that a requirement source is self-derived, identify the
redundant subpath and remove it to produce a new, smaller requirement
source that computes the same result. We were doing this form the
limited case where the redundant subpath ended at the end of the
requirement source; generalize that notion.
Fixes SR-5601.
We break name lookup circularities by special-casing validation of
type aliases, resolving the underlying type of the type alias before
building the generic environment of the protocol that contains the
type alias.
However doing this gives the type alias an underlying type written
in terms of unresolved DependentMemberTypes which do not map to
associated types.
Attempting to substitute such a type fails.
We worked around this by re-validating type alias members of
protocols when we finally got around to building the protocol's
generic environment. Force this to happen earlier in
substMemberTypeWithBase(), because we need the fully resolved
underlying type in order to perform the substitution.
Also, fix TypeAliasDecl::setUnderlyingType() to only create a new
NameAliasType the first time it is called. In this special case
where it can be called twice with a resolved underlying type the
second time, we should not be creating a new NameAliasType.
There are better fixes possible here, requiring various levels
of refactoring. I'll investigate this soon, but for now this narrow
fix should address the problem with minimal risk.
Fixes <rdar://problem/33189068>.
While trying to validate Objective-C keypath components
don't assume that type of the component is always correct, check
before trying to see if it's bridged type or has members.
Resolves: rdar://problem/33044867
The change to roll back a part of SE-0110 to allow multi-argument
functions to be passed in places where functions taking a tuple are
expected resulted in a regression in some cases where the fix would
strip off the last ParenType from single-argument functions.
Instead of stripping off parens from both function types we're trying to
match when they both have them, strip off none. This ensures that we
don't get summarily rejected in the nested matchTypes call by other
SE-0110-related code that bails if the two types do not have the same
"parenness".
Fixes rdar://problem/33043106 / SR-5387.
This reverts commit 70deaa89e2.
My next commit already added the same test case, but this reverted
commit added it in a way that the test will fail with my fix in place.
If we encounter an associated type reference within a concrete type, but
haven't seen a specific protocol requirement, add the protocol
conformance.
Fixes rdar://problem/33139928 and another crasher.
While trying to diagnose problems related to keypath components
don't assume that type of the component is always correct, check
before trying to see if it's bridged type or has members.
Resolves: rdar://problem/33135487
- Deinitializers never get a custom Objective-C name.
- Classes and protocols are never bridged themselves; that only matters
for structs and enums.
This avoids another circularity issue like the one in a8bc132565,
where the Clang importer ends up importing a class and hands it to the
type checker, which then asks about conformances. The conformance
lookup table goes to add the extension from the Swift module, except
that the Swift module is what asked for the import in the first place.
It's possible there's a more general solution here, but this
particular change is good even in the non-crashy cases, and definitely
safe for Swift 4.0. Even if the test case is even more idiosyncratic
than the last one.
The test case change for SourceKit is probably due to the first
category not triggering the import of the other two
categories. Changes in import order have been known to affect source
compatibility, though not frequently. However, categories are not
intended to be ordered in the first place. There's still more we can
do in this space, and implicitly depending on these calls /outside/ of
the importer to control category import order was quite brittle
anyway.
SR-5330 / rdar://problem/32677610
Fixes crasher in diagnostics related to the fact that contextual type
is not always available when trying to diagnose problems related to
calls with trailing closures.
Resolves: rdar://problem/33067102
The small-but-significant change to the generic signature builder is
to refuse to create unresolved potential archetypes. Instead, delay
any requirement that depends on such type, to be reprocessed once
we've seen all of the other requirements. If the type can be resolved
later, it will be; Otherwise, the type checker will complain when it
sees an unresolvable type. By itself, this fixes the crash in SR-2796.
Doing this by itself regresses diagnostics because typo correction in
the generic signature builder no longer kicks in. Therefore, implement
typo correction for these cases in the type checker proper, using its
existing facilities for typo correction. The result is more consistent
code with a better result.
Fixes SR-2796 / rdar://problem/28544316.
When a concrete requirement is invalid due to the concrete type
lacking a conformance to a particular, required protocol, don't emit
that incorrect requirement---it causes invalid states further down the
line.
Fixes SR-5014 / rdar://problem/32402482.
While here, fix a comment that Huon noticed trailed off into oblivion.
When we see two type(aliase)s with the same name in a protocol
hierarchy, make them equal with an implied same-type requirement. This
detects inconstencies in typealiases across different protocols, and
eliminates the need for ad hoc consistency checking. This is a step
toward simplifying away the need for direct-diagnosis operations
involving concrete type mismatches.
While here, warn when we see an associated type with the same as a
typealias from an inherited protocol; in this case, the associated
type is basically useless, because it's going to be equivalent to the
typealias.
Centralize and simplify the handling of conformance requirements
resolved by same-type-to-concrete requirements in a few ways:
* Always store a ProtocolConformanceRef in via-superclass and
via-concrete requirement sources, so we never lose this information.
* When concretizing a nested type based on its parent, use the
via-concrete conformance information rather than performing lookup
again, simplifying this operation considerably and avoiding
redundant lookups.
* When adding a conformance requirement to a potential archetype that
is equivalent to a concrete type, attempt to find and record the
conformance.
Fixes SR-4295 / rdar://problem/31372308.
