Term prefixed with underscore considered ambiguous when it shouldn't be (and round-trip issue)

[alvaroc1]

Version: release/0.5.16

type Hello = {_value : Nat}

doStuff = _value.modify

There's only one definition of _value in the project, coming from the Hello type.

It works fine with a longer prefix or without the underscore

When editing, the pretty-printer prints it as shown also causing round-trip issues.

[andreystepanov]

There's also a weird behaviour when you're trying to edit some of the generated functions (either intentionally, or they might get spitted out on update command related to other custom definitions).

Let's expand @alvaroc1's example a bit to:

type Hello = { _value : Nat, value : Nat, value_ : Nat }

Now run edit Hello._value command, and see how editor's LSP starts complaining with:

  I found a value  of type:  Hello ->{𝕖} Nat
  where I expected to find:  Nat

      1 | Hello._value : Hello -> Nat
      2 | Hello._value = cases Hello _value -> _value

    from right here:

      1 | Hello._value : Hello -> Nat

But running edit Hello.value (without _ prefix) would not have the same issues. The same applies to Hello.value_ version.

Which tells us that compiler having trouble capturing variables in pattern match case when they start with _ (underscore).

I'm not sure if it's somehow related to #4746, but worth the mention.

[sellout]

Duplicate of #2822.