[Wildcard Variables] DDC Implementation

[kallentu]

This issue tracks the work needed for the wildcard variables feature to be supported in DDC.
Spec: https://github.com/dart-lang/language/blob/main/working/wildcards/feature-specification.md

We may need to do some additional work to support multiple wildcard parameters in functions.

class A {
  int add(int a, int b) => 3;
}

class C implements A {
  int add(int _, int _) => 3;
}

cc. @sigmundch Feel free to tag or reassign as you see fit.
I'd also appreciate more details so we don't lose that context.

[sigmundch]

Thanks @kallentu

• the work here depends a lot on what kind of lowering we end up doing in the CFE
• the lowering will likely convert the wildcard variables into something, potentially a variable declaration that is never read.
• if the lowering uses the existing representation of variable declarations and guarantees uniqueness of variable names like today parameters have, then the backend may not need to do anything special for it to generate valid JavaScript. However, if the variable is represented by a new kernel node or a node that breaks current invariants, we may need some relatively small amount of work to emit valid JavaScript function declarations. The work could be similar to what DDC already does for temporary variables in Let expressions.
• Aside from implementing the feature, the debugger support may not need much work either. We need however to have consistent semantics in expression evaluation. If in the body of the method an expression to be evaluated uses _, we need to decide if it is rejected and, if not, what to generate in that case.

[nshahan]

Depending on how the CFE lowers the wildcards, and how we want them to appear (or not appear) in the debugger there could likely be some collaboration needed between DDC and DWDS to get it working.
cc @bkonyi

[kallentu]

If there's work for web debugging, I've created an issue to track that: #55752

[bkonyi]

I was under the assumption that the spec specified that wildcard variables won't be bound to a variable and that there will be no way to reference them. Is that not the case? Regardless, I don't think we want them to appear in the debugger, especially since we can have multiple wildcard variables in the same scope.

[sigmundch]

Correct - I think the nuance here is that in the code we emit in JavaScript we need to introduce a placeholder name to generate a valid function signature.

While our intent was to eventually make dwds model all of its state based on what we know from the dart program, there were cases in the past where it created its internal model based on the Chrome debugger's state of the application. If that is still the case today, we may need to do some work to ensure those synthetic variables are properly ignored/hidden.