It was used for unresolved member and `.dynamicType` references
as well as a couple of other places, but now unresolved member
references no longer need that due to new implicit "chain result"
AST node and other places could use more precise locators
e.g. new `.dynamicType` locator or `sequence element` for `for in`
loops.
Solver needs to handle invalid declarations but only in
"code completion" mode since declaration in question might
not be associated with code completion, otherwise (if constraint
generation fails) there is going to be no completion results.
* [AST] Add 'FloatingPoint' known protocol kind
* [Sema] Emit a diagnostic for comparisons with '.nan' instead of using '.isNan'
* [Sema] Update '.nan' comparison diagnostic wording
* [Sema] Explicitly check for either arguments to be '.nan' and tweak a comment
* [Test] Tweak some comments
* [Diagnostic] Change 'isNan' to 'isNaN'
* [Sema] Fix a bug where firstArg was checked twice for FloatingPoint conformance and update some comments
* [Test] Fix comments in test file
* [NFC] Add a new 'isStandardComparisonOperator' method to 'Identifier' and use it in ConstraintSystem
* [NFC] Reuse argument decl extraction code and switch over to the new 'isStandardComparisonOperator' method
* [NFC] Update conformsToKnownProtocol to accept DeclContext and use it to check for FloatingPoint conformance
Allow an 'async' function to overload a non-'async' one, e.g.,
func performOperation(_: String) throws -> String { ... }
func performOperation(_: String) async throws -> String { ... }
Extend the scoring system in the type checker to penalize cases where
code in an asynchronous context (e.g., an `async` function or closure)
references an asychronous declaration or vice-versa, so that
asynchronous code prefers the 'async' functions and synchronous code
prefers the non-'async' functions. This allows the above overloading
to be a legitimate approach to introducing asynchronous functionality
to existing (blocking) APIs and letting code migrate over.
Instead of creating the type variable for the unresolved member chain at the location of the last member, we now create it at the associated UnresolvedMemberChainResultExpr.
Previously, when the final element of a chain was a ForceValueExpr, the chain result type got caught up in the logic used to allow ForceValueExprs to properly infer lvalue types. By separating the result type variable from the last member of the chain, we make sure to keep that logic focused only on ForceValueExpr.
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
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.
