[CodeCompletion] Improve context type analysis #18564
Conversation
|
@swift-ci Please smoke test |
|
@benlangmuir I'm doing this because I want to use |
There was a problem hiding this comment.
Overall this patch looks great! More correct and less complex.
Could you explain more about what effect this has:
Always activate CodeCompletionExpr so we don't interfere typechecking contexts.
I wasn't aware of this flag; why were we skipping CSGen for code completion expressions before?
| if (CE->hasExplicitResultType()) | ||
| return const_cast<ClosureExpr *>(CE) | ||
| ->getExplicitResultTypeLoc() | ||
| .getType(); |
There was a problem hiding this comment.
Why isn't this just set as the result type?
There was a problem hiding this comment.
I haven't looked into it yet, but probably, if the type checker fails to type check the body of single expression closure, type checking for closure also fails.
lib/IDE/CodeCompletion.cpp
Outdated
| break; | ||
| } | ||
| default: | ||
| llvm_unreachable("Unhandled pattern kinds."); |
There was a problem hiding this comment.
Nitpick: it should be "kind" singular.
lib/IDE/CodeCompletion.cpp
Outdated
| @@ -1510,12 +1510,19 @@ static Type getReturnTypeFromContext(const DeclContext *DC) { | |||
| if (auto FD = dyn_cast<AbstractFunctionDecl>(DC)) { | |||
| if (FD->hasInterfaceType()) { | |||
| if (auto FT = FD->getInterfaceType()->getAs<FunctionType>()) { | |||
| if (FD->getDeclContext()->isTypeContext()) | |||
| FT = FT->getResult()->castTo<FunctionType>(); | |||
There was a problem hiding this comment.
You can use getMethodInterfaceType() here
To be honest, I don't know. |
There's no reason not to activate them.
* For methods, un-curry function interface type so we can get declared return type. * For closures, fall back to getting explicit result type in case we cannot retrieve it from the type of closure itself.
…lyzer Don't discard parsed expression in Parser. This improves type inference for CodeCompletionExpr.
in 'ExprParentFinder'. There's no reason to re-pack into ASTNode.
This improves type inference for code completion in argument position of EnumElementPattern.
* Don't need to look for CodeCompletionExpr. It's wrong anyway because what we are looking for is not neccessarily a 'CodeCompletionExpr'. * Use getElementLoc(i).isValid() instead of !getElementName(i).empty(). Just in case users write '_:' for call argument. * Don't suggest argument labels for implicit call expression. For instance, string interpolation segments.
rintaro
force-pushed
the
ide-completion-contextanalysis
branch
from
043aa25 to
137ca65
Compare
|
@swift-ci Please smoke test |
CodeCompletionExprso we don't interfere typechecking contexts.ExprPatternin context type analysis. This improves completion in matching pattern.getPositionInArgs()([IDE][NFC] Cleanup collectArgumentExpectation() #18535 (comment))