SwiftUI: Failed to produce diagnostic for expression when using keyword 'open' in some contexts

[j-war]

Describe the bug
Xcode/Swift/VSCode fail to notice that the variable has not been defined in some contexts.

Steps To Reproduce

1. Attempt to use an undefined variable in the following context where the name is also a keyword.
2. See following code that fails to compile and fails to provide a useful reason why.

Expected behavior
A notice that the variable was not defined rather than "failed to produce diagnostic for expression; please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project sourcekitd".
Or, a notice that the use of 'open' is incorrect as it's a keyword.

Screenshots
N/A

Environment (please fill out the following information)

• OS: macOS 13 beta 7
• Xcode Version/Tag/Branch: 14.0 RC or VS Code 1.71.0 with Swift extension 0.8.1

import SwiftUI
struct MyView: View {
   // var open = true
   var body: some View {
       Button {
           // no action
       } label: {
           Image(systemName: "plus")
               .rotationEffect(.degrees(open ? 45 : 0)) // Using keyword 'open'
       }
   }
}

Additional context
Placing the 'open ? 45 : 0' inside of another context, say a print(), correctly identifies the issue of an undefined variable.

[xedin]

No ambiguity logic for [fix: ignore specified contextual type] @ locator [If@<stdin>:9:46 -> condition expression]

[dfperry5]

@xedin / @AnthonyLatsis - is this still a problem? If so, is it open for me to take a shot at?

[j-war]

Yes. Xcode 15 beta 1,

[xedin]

Please feel free to take it, I don’t think anybody is working on this at the moment.

[AnthonyLatsis]

@dfperry5 Issues that are not assigned to anyone and show no signs of recent activity are yours for the taking. In other cases, the etiquette is to first ask the assignee or last person to have claimed it whether they’re (still) working on it. Note that an assignee need not imply that the person ever worked on the issue: some contributors like myself use assignments to simply bookmark issues.

---

Please let us know if you want to be assigned to this.

[dfperry5]

@AnthonyLatsis - Please assign this one to me! Sorry for the delay, took a vacation and we're just getting back :)

[AnthonyLatsis]

A more illuminating reproduction:

func `open`(_: Int) {}
func `open`(_: Bool) {}

func degrees(_: Int) {}
do {
  degrees(open)
}

And a reduced version of the original example:

import SwiftUI
struct MyView: View {
  var body: some View {
    Color.black.rotationEffect(.degrees(open))
  }
}

[dfperry5]

@AnthonyLatsis - been taking a peak at this and am feeling a little stuck. I see where it calls " DE.diagnose(expr->getLoc(), diag::type_of_expression_is_ambiguous)
.highlight(expr->getSourceRange());" in ConstraintSystem.cpp, but I can't figure out a way to have it check if there are any keywords in that expression.

Any thoughts or suggestions would be much appreciated :)

[AnthonyLatsis]

Hi Dylan,

The overloaded name is irrelevant, you can try foo instead of open to confirm. The problem is that we are not properly diagnosing an ambiguity when neither of several overloads have a type that is compatible with the contextual, parameter type (Pavel left a hint here). A specific ConstraintFix gets recorded for this kind of type mismatch in the constraint system; from what I understand, this ConstraintFix subclass is lacking a custom override of the diagnoseForAmbiguity method.

[dfperry5]

@AnthonyLatsis / @xedin - sorry to bug ya'll (and for the radio silence for a while). But, I am struggling with this issue still. In my debugging I am seeing

"[fix: allow argument to parameter type conversion mismatch]" which leads me to believe we are trying to apply the AllowArgumentMismatch subclass of ContextualMismatch. This type did not have a diagnoseForAmbiguity override. I created the function, AllowArgumentMismatch::diagnoseForAmbiguity, and can see it being called.

I'm fuzzy on the logic that should be applied within that function though. Will continue playing around - but if you get time - some guidance would be appreciated! :)

[xedin]

I don't think we should not add diagnoseForAmbiguity to AllowArgumentMismatch because it's intended only for situations where it's exactly the same fix but in different context. This is not the case for AllowArgumentMismatch because each fix denotes a different overload's parameter type (for the same argument type) which means we cannot diagnose that as a single error message, it was to be an ambiguity diagnostic that is produced by diagnoseAmbiguityWithFixes.

[dfperry5]

@xedin just to make sure I'm following - the thought here is that diagnoseAmbiguityWithFixes should be what produces the appropriate error message, not an override specific to AllowArgumentMismatch:: diagnoseForAmbiguity?

[xedin]

Yes, that is correct.

[dfperry5]

I got to admit I am pretty stuck here - I can see the it flowing through diagnoseAmbiguityWithFixes - but I'm not sure how to catch the specific error here.