[Diagnostics] Port diagnostics from FailureDiagnosis::visitObjectLiteralExpr #29304
Conversation
|
Thank you, @LucianoPAlmeida! I'll take a look on Monday/Tuesday. |
lib/Sema/CSSimplify.cpp
Outdated
| @@ -1036,6 +1036,34 @@ ConstraintSystem::TypeMatchResult constraints::matchCallArguments( | |||
| if (cs.recordFix(fix, /*impact=*/extraArguments.size() * 5)) | |||
| return cs.getTypeMatchFailure(locator); | |||
| } | |||
| } else if (args != params && cs.shouldAttemptFixes() && | |||
| !cs.hasFixFor(loc)) { | |||
| if (auto *expr = dyn_cast<ObjectLiteralExpr>(loc->getAnchor())) { | |||
There was a problem hiding this comment.
I think this special case here is unnecessary because it should be possible to generate applicable fn constraint in visitObjectLiteralExpr and let to solver handle the rest (currently it calls into matchCallArguments directly which is not optimal). Could you give it a shot?
There was a problem hiding this comment.
Could you give it a shot?
For sure 👍
test/Sema/object_literals_osx.swift
Outdated
|
|
||
| // rdar://problem/49861813 | ||
| #fileLiteral() // expected-error {{cannot convert value of type '()' to expected argument type '(resourceName: String)'}} | ||
| #fileLiteral() // expected-error {{missing argument label 'resourceName:' in call}} |
There was a problem hiding this comment.
To be precise the problem here is not the absence of label alone but the argument type as well...
lib/Sema/CSSimplify.cpp
Outdated
| // Attempt diagnose and maybe suggest import the correct module for | ||
| // ObjectLiteral expr. | ||
| if (cs.shouldAttemptFixes()) { | ||
| if (auto *fix = SpecifyObjectLiteralTypeImport::attempt(cs, loc)) { |
There was a problem hiding this comment.
The way failure manifests here is related to solver being unable to infer type of _ExpressibleByFileReferenceLiteral which is connected to result of the call by literal conforms constraint. I think the way we should approach it - mark type variable representing a result of ObjectLiteralExpr as "potential hole" while generating constraints for ObjectLiteralExpr expression and record a fix in TypeVariableBinding::attempt just like we do for generic parameters and closure result type.
There was a problem hiding this comment.
Doing it that way eliminates a need for attempt since we'll know exactly what happened.
lib/Sema/CSFix.cpp
Outdated
| if (!isa<ObjectLiteralExpr>(anchor)) | ||
| return nullptr; | ||
|
|
||
| if (cs.getContextualType()) |
There was a problem hiding this comment.
This condition should be removed since we know exactly that the problem is related to solver's inability to infer result type of the ObjectLiteralExpr. Also it should have been getContextualType(anchor) otherwise it might be contextual to completely different expression...
LucianoPAlmeida
force-pushed
the
port-object-literal-diagnostics
branch
from
081a556 to
7a564e5
Compare
LucianoPAlmeida
force-pushed
the
port-object-literal-diagnostics
branch
5 times, most recently
from
e504b22 to
0bf3704
Compare
… attempting literal result type variable binding and handle object literal in MissingArgumentsFailure
LucianoPAlmeida
force-pushed
the
port-object-literal-diagnostics
branch
from
43fbbab to
f07e21b
Compare
…mport and fix string description
|
@xedin Nit's fixed 👍 |
|
@swift-ci please smoke test |
|
Thank you for helping along with the new diagnostics effort! |
|
+1! Thank you, @LucianoPAlmeida! |
No problem! Happy to help :) Thank you for the reviews @xedin :) |
Ports the
FailureDiagnosis::visitObjectLiteralExprfrom CSDiag to the new framework.cc @xedin @hborla :)