func foo(a: Int, b: Int) {}
func foo(a: String) {}
// Int and String should both be valid, despite the missing argument for the
// first overload since the second arg may just have not been written yet.
foo(a: <complete here>
func bar(a: (Int) -> ()) {}
func bar(a: (String, Int) -> ()) {}
// $0 being of type String should be valid, rather than just Int, since $1 may
// just have not been written yet.
bar { $0.<complete here> }
This check did not handle MemberRefExprs with an InOutExpr base,
giving it inconsistent behavior:
- With a class, we would diagnose self-assignment of computed
properties
- With a struct, accesses to computed properties would build a
MemberRefExpr with an InOutExpr base, so self-assignments
were *not* diagnosed.
Let's tweak the check to consistently diagnose self-assignments
to stored properties only, instead of the emergent behavior
as described above.
This method had a messy contract:
- Setting the diags parameter to nullptr inhibited caching
- The initExpr out parameter could only used if no result
had yet been cached
Let's instead use the request evaluator here.
Rework the data structures we use in the conformance checker to talk
about missing witnesses, so they can capture the set of potential
matches. This will allow us to delay more diagnostics to later,
more uniformly.
The lack of these functions in a function builder is diagnosed in
different places in the type checker. Extend these diagnostics to
provide stubs in the function builder.
Thanks to Suyash for the suggestion!
When performing code completion inside the declaration of a type with
the function builder attribute, also include completions for all of
the possible "build" functions.
When a use of a function builder involves a statement kind that the
function builder doesn't support (e.g., if-else), add a note to the
diagnostic that specifies what methods need to be added to the
function builder to support that statement, including Fix-Its with
stub implementations.
* [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
We previously were not properly handling the diagnostics for using an rvalue implicit member on the left hand side of an assignment. This adds the proper handling and extends it for member chains.
Move the analysis and transformation of unresolved member chains into the PreCheckExpression pass in order to make sure that contextual types get hooked up properly before we actually begin generating constraints.
The old method of generating this placeholder expression caused issues when constraints had to be recursively regenerated during solving. Now, we generate UnresolvedMemberChainResultExprs in walkToExprPre, and use ASTWalker::Parent instead of ConstraintSystem::getParentExpr to find the parent of the chain tail.
This also lets us generate the chain constraints as part of the normal ConstraintGenerator visit, rather than as an extra walkToExprPost step.
* [CSDiagnostics] Emit fix-its to insert requirement stubs in editor mode for missing protocols in context
* [CSDiagnostics] Only include missing requirements in stub fix-it for missing protocols in context
The conforming type may already have declarations that could satisfy a requirement, so we shouldn't include it in the fix-it
LLVM, as of 77e0e9e17daf0865620abcd41f692ab0642367c4, now builds with
-Wsuggest-override. Let's clean up the swift sources rather than disable
the warning locally.
