If one of the cases is invalid, let's mark parent enum as invalid
as well, and avoid trying to derive any conformances related to it.
Resolves: rdar://problem/36989792
As a minor step toward more global associated type inference,
allow tentative type witnesses to be found across a protocol
hierarchy, eliminating some recursion through associated type
inference. Fixes a recent regression in validation-test/stdlib/CollectionTypes.swift, as well as rdar://problem/36453271.
If something that we are trying to contextually bind is a nested type inside
protocol or protocol extension, let's try to find the innermost conforming type
from the current declaration context and map Self parameter of the protocol
to that nominal type. Since nested types in protocols aren't yet implemented this
is going to result in failure, but that's better than crashing.
Resolves: rdar://problem/36449760
* Remove a bunch of Default(Bidirectional|RandomAccess)Indices usage from stdlib and test
* Remove some DefaultRandomAccessIndices and IndexDistance usage from Foundation
* Remove no-longer-used internal type in Existentials.swift
* Get rid of indicesForTraversal
Redeclaration checking was validating all declarations with the same
base name as the given declaration (and in the same general nominal
type), even when it was trivial to determine that the declarations
could not be conflicting. Separate out the easy structural checks
(based on kind, full name, instance vs. non-instance member, etc.) and
perform those first, before validation.
Fixes SR-6558, a case where redeclaration checking caused some
unnecessary recursion in the type checker.
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.
