Internal IR representation 'leaked' in stack trace of a dataflow error thrown from a suspended argument with default value

[radeusgd]

from Standard.Base import all

main =
    r = [].find (>0)
    IO.println r.get_stack_trace_text

prints

        at <enso> <default::Vector.find::Name.Literal(name = if_missing, isMethod = false, location = Some(IdentifiedLocation[location=Location[start=13071, end=13081], uuid=None]), passData = MetadataStorage[], diagnostics = DiagnosticStorage(diagnostics = List()), id = fee33391-2ebd-417a-9d3b-09d7708643e0)>(Internal)

We can see that the location contains a long-form text representation of the if_missing default argument. This makes the stack trace harder to read, if not to say a bit 'ugly'.

I think the expected behaviour would be something like:

        at <enso> <default::Vector.find::if_missing>(Internal)

[radeusgd]

Alternative repro not relying on Vector, and showing that the problem is related only to suspended arguments with defaults:

from Standard.Base import all
import Standard.Base.Errors.Illegal_Argument.Illegal_Argument

foo1 x y=(Error.throw (Illegal_Argument.Error "y is not set :)")) =
    x+y

foo2 x ~y=(Error.throw (Illegal_Argument.Error "y is not set :)")) =
    x+y

main =
    IO.println "foo1:"
    r1 = foo1 42
    IO.println r1.get_stack_trace_text

    IO.println "foo2:"
    r2 = foo2 42
    IO.println r2.get_stack_trace_text

foo1:
        at <enso> stacks.foo1(X:\NBO\repr\stacks.enso:4:11-64)
foo2:
        at <enso> <default::stacks.foo2::Name.Literal(name = y, isMethod = false, location = Some(IdentifiedLocation[location=Location[start=184, end=185], uuid=None]), passData = MetadataStorage[], diagnostics = DiagnosticStorage(diagnostics = List()), id = faf9792f-d61a-46d4-b69a-c6f55897667b)>(Internal)

[radeusgd]

btw. in the example above, shouldn't the foo1 actually also point to the default as the location of the error, instead of foo1? Moreover, in foo2 the source code location should also be present and not just be Internal.

IMHO both locations should be the same, regardless of if the argument is suspended or not, because I don't see how the argument being suspended should influence its location.

So perhaps the Expected behaviour for the example above shall be following?

foo1:
        at <enso> <default::stacks.foo1::y>(X:\NBO\repr\stacks.enso:4:11-64)
foo2:
        at <enso> <default::stacks.foo2::y>(X:\NBO\repr\stacks.enso:7:11-64)

OR

foo1:
        at <enso> stacks.foo1(X:\NBO\repr\stacks.enso:4:11-64)
foo2:
        at <enso> stacks.foo2(X:\NBO\repr\stacks.enso:7:11-64)

(the stacks in the examples comes from the filename of the script being run being stacks.enso)