Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Since the two ExtInfos share a common ClangTypeInfo, and C++ doesn't let us
forward declare nested classes, we need to hoist out AnyFunctionType::ExtInfo
and SILFunctionType::ExtInfo to the top-level.
We also add some convenience APIs on (AST|SIL)ExtInfo for frequently used
withXYZ methods. Note that all non-default construction still goes through the
builder's build() method.
We do not add any checks for invariants here; those will be added later.
Make sure we consistently use getParentForLookup() and not getParent()
when looking at generic DeclContexts. This is because an extension or
protocol that is nested inside of another generic context must never
inherit generic parameters from the parent context.
We already had this invariant enforced in some places, but now that we
do it more consistently we can fix more crashes of this kind.
Fixes <rdar://problem/58813746>, <https://bugs.swift.org/browse/SR-13004>.
* [TypeCheckConstraints] Adjusting cases where checked casts that cannot be determined statically were producing misleading warnings
* [tests] Adding regression tests for SR-13088
* [TypeCheckConstraints] Adjusting comment and adding an extra test case for SR13035
* [TypeCheckConstraints] Fixing typos in comments
* [AST] Moving implementation of isCollection from ConstraintSystem to AST TypeBase
* [TypeCheckConstraints] Adjusting logic to verify specific conformance to stdlib collection type before emit an downcast warning
* [TypeCheckConstraints] Creating new CheckedCastContextKind::CollectionElement to be able to verify special cases within typeCheckCheckedCast for collection elements
* [TypeCheckConstraints] Adjusting logic around generic substitution to check both subtype and supertype
* [Sema] Adding isKnownStdlibCollectionType and replacing all usages contraint system method
* [TypeChecker] Reverting fixes around array element types
* [TypeChecker] Abstract logic of check for conditional requirements on TypeChecker::couldDynamicallyConformToProtocol
* [TypeChecker] Ajdustinc can conformDynamically conform and adjust review comments
* [TypeChecker] Ajusting comments and fixing typos
* [TypeChecker] Adjusting existential and archetype logic to check inside couldDynamicConform
* [TypeChecker] Adjusting minor and adding existential check into couldDynamically conform.
* [TypeChecker] Adjusting comments
If the problem is related to an operator and argument is an enum
with associated values mention that conformances to `Equatable`
and `Comparable` are not synthesized in such cases.
Currently it's possible to have a type conflict between different
requirements deduced as the same type which leads to incorrect
diagnostics. To mitigate that let's adjust how "fixed" requirements
are stored - instead of using resolved type for the left-hand side,
let's use originating generic parameter type.
Instead of special casing argument-to-parameter matching for
object literal expressions, let's allow constraint system to
lookup a witness initializer and apply it to the given set
of arguments.
This also simplifies constraint application because
`coerceCallArguments` could be used to form type-checked
argument expression.
If aggregate fix (based on callee locator) differs only in picked
overload choices, let's diagnose that via `diagnoseForAmbiguity`
associated with a particular fix kind all solutions share, that
would produce a tailored diagnostic instead of the most general one.
Refactor `diagnoseAmbiguityWithFixes` as follows:
- Aggregate all of the available fixes based on callee locator;
- For each ambiguous overload match aggregated fixes and diagnose;
- Discard all of the fixes which have been already considered
as part of overload diagnostics;
- Diagnose remaining (uniqued based on kind + locator) fixes
iff they appear in all of the solutions.
