[dart devc] Pattern matching use same variable name cause unexpected behavior

[huanghui1998hhh]

Steps to reproduce

Create a flutter project and run flutter web on debug mode with this code:

void main() {
  String? fooValue = 'hello world';
  if (fooValue case final String fooValue) {
    print(fooValue);
  }
}

And this is it's js result:

  main.main = function main$() {
    let fooValue = "hello world";
    {
      let fooValue = null;
      let t$36$350$350 = fooValue;
      if (typeof t$36$350$350 == 'string') {
        fooValue = t$36$350$350;
        {
          core.print(fooValue);
        }
      }
    }
  };

So it will not print 'hello world'.

[eernstg]

Drive-by comment (I'm working on the language, not on the implementation of compilation to JavaScript in any tool).

@huanghui1998hhh, what's your configuration? With dart compile js on your example program (no optimization options) I get the following:

    main() {
      A.printString("hello world");
    }

Perhaps your issue should be classified as a DDC issue? Also, the kernel code looks as follows (but note that there may be differences between the kernel code generated for different backends):

  static method main() → void {
    core::String? fooValue = "hello world";
    {
      final hoisted core::String fooValue;
      final synthesized core::String #0#0 = fooValue{core::String};
      if(#0#0 is core::String) {
        fooValue = #0#0;
        {
          core::print(fooValue);
        }
      }
    }
  }

It looks similar to your JavaScript code, but there may be some rules about the meaning of hoisted that matter.

[mraleph]

@eernstg the issue title indicates it's a Flutter Web debug mode - which means DDC.

[mraleph]

cc @nshahan

[huanghui1998hhh]

Yes, this is a DDC issue. Maybe I should use tag dart devc. sry

[nshahan]

@johnniwinther

Inspecting the kernel for this example shows that the shadowing fooValue variable gets declared before the temporary used in the pattern which is too early. Is this something specific to the lowering used in DDC?

[rakudrama]

Look deeper into the 'shadowing'.
I think it is possible that Kernel can represent a program where every variable is renamed to x, but they are disambiguated since the references point to the declaration. There is no lookup of the name to find the variable, parsing to Kernel has done that already, so the name has no effect on the semantics.

DDC could fix this by generating different JavaScript names for shadowed names, either avoiding shadowed names entirely, or doing some analysis to tell if the separate JavaScript names are needed to express the correct lookup in the generated code's scope structure.

The Kernel printer could also disambiguate 'shadowing' by adding a suffix or other annotation to distinguish variables in nested scopes with the same name , e.g. using fooValue₁ instead of fooValue for one of the variables.

[johnniwinther]

It is unfortunate that the lowering introduces was looks like a shadowing. I'll see if we can avoid this.

[rakudrama]

There is a broader issue - the user program has two variables with the same name.
How does one debug a program with shadowed variables?

I believe currently that the DDC generated code has a JavaScript scope model that is mostly in alignment with the Dart model, so the debug experience works.
Ideally it should be possible during single-stepping to assign to variables and continue.

Johnni - what changes were you thinking of?

The CFE should not change user variable names. It might be possible to rearrange the lowered code so that the scopes don't 'interleave' like in the Kernel snippet. Can that the scopes be arranged to be non-interleaved in the general case?
If the interleaving is necessary, how does Kernel indicate which variables are visible on the Dart scope chain?

/cc @annagrin

[nshahan]

I agree, there is shadowing present in the original source code and it would provide the most consistent user experience in the debugger if the shadowing still exists. Along with a change to where the hoisted variable is declared so that doesn't break the initialization of the synthetic variable.