TCO is not properly applied when function encounters a value with warnings attached

[radeusgd]

It is possible to trigger a stack-overflow in methods which rely on @Tail_Call to avoid that exact issue and work for larger datasets.

The Vector.contains can be tripped and trigger a stack overflow on a vector with as little as 1000 elements.

Run the following program:

from Standard.Base import all

main =
    v = Vector.new 1000 (i-> i+1)
    elem = Warning.attach "WARNING" 998
    IO.println (v.contains 998)
    IO.println (v.contains elem)

Expected behaviour

True
True

Actual behaviour

It fails with stack overflow:

True
Execution finished with an error: Resource exhausted: Stack overflow
        at <enso> go(Internal)
        at <enso> go<arg-2>(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:486-487)
...
        at <enso> go<arg-2>(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:486-487)
        at <enso> go(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:485-487)
        at <enso> Range.find_internal(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:488:5-24)
        at <enso> <anonymous>(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:338:22-60)
        at <enso> Range.check_start_valid<arg-2>(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:477:13-31)
        at <enso> Range.check_start_valid<arg-2>(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:476-477)
        at <enso> Range.check_start_valid(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:472-477)
        at <enso> Range.find(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:337-339)
        at <enso> Range.any<arg-0>(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:318:26-44)
        at <enso> Range.any<arg-0>(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:318:26-57)
        at <enso> Range.any(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Range.enso:318:26-63)
        at <enso> Vector.any(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Vector.enso:368:9-68)
        at <enso> Vector.contains(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Base\0.0.0-dev\src\Data\Vector.enso:394:26-49)
        at <enso> stackoverflow1.main<arg-1>(stackoverflow1.enso:7:17-31)
        at <enso> stackoverflow1.main(stackoverflow1.enso:7:5-32)

[hubertp]

This has regressed in #6849. And I'm not surprised as I wasn't entirely convinced by that change.

[enso-bot]

Hubert Plociniczak reports a new STANDUP for the provided date (2023-06-23):

Progress: Preparing a PR with a solution. Seems to cover the problem without any perf impact. Started looking into #7002. Reviewing changes to Any. It should be finished by 2023-06-23.

Next Day: Next day I will be working on the #7002 task. Provide a PR with a change.

[enso-bot]

Hubert Plociniczak reports a new STANDUP for the provided date (2023-06-22):

Progress: Finding regression for #7098 (aka #6994). Investigating #7093 - I think I found an elegant solution with a negligible perf impact. It should be finished by 2023-06-23.

Next Day: Next day I will be working on the #7093 task. Provide a PR with a fix for #7093.