roc test: entered unreachable code: no borrow signature for LambdaName

[phtrivier]

• Using "ubuntu mate 24.04" on an x86_64

○ → lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   8
  On-line CPU(s) list:    0-7
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz

○ → lsb_release --all
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.1 LTS
Release:	24.04
Codename:	noble

• Using a recent nighly

○ → roc --version
roc nightly pre-release, built from commit a089cf2 on Di 07 Jan 2025 09:02:06 UTC

Given two files:

• Foo.roc :

module [
    foo,
]

foo = { bar: 42 }

• main.roc

app [main!] { pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.18.0/0APbwVN1_p1mJ96tXjaoiUCr8NBGamr8G8Ac_DrXR-o.tar.br" }

import pf.Stdout
import Foo

expect
    f = Foo.foo
    f.bar == 42

main! = \_args ->
    try Stdout.line! "Ok"
    Ok {}
    

When running roc test:

thread 'main' panicked at crates/compiler/mono/src/inc_dec.rs:984:33:
internal error: entered unreachable code: no borrow signature for LambdaName { name: `Foo.foo`, niche: Niche(Captures([])) } layout
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

If i replace the expectation with:

expect Foo.foo.bar == 42

Then test is successful:

○ → roc test
0 failed and 1 passed in 215 ms.

[Anton-4]

Thanks for the detailed error report @phtrivier :)

Notes for a future investigator: We have several issues with "no borrow signature for LambdaName" but this is the only one that panics in crates/compiler/mono/src/inc_dec.rs

[jwoudenberg]

Don't know if it's useful: but I'm also running into this after updating rvn to the latest version.

The update encompasses changing camelCased standard-library functions to snake_case, updating to the new lambda syntax, and replacing && and || with and and or. That suggest this particular version of the bug was introduced in the last month or so.

Before the update I was on compiler commit 32e0ea38ef6b158c37e280eec8e08a041eac13b1, and the same code except for the changes above worked then.

[jwoudenberg]

I've done a bit of a bisect to find the commit at which the compiler starts producing this error for me:
99dfc55

This is before the breaking changes in the standard library, so the current RVN code on main (commit) runs fine up to that commit, and fails with that change.

[Anton-4]

Thanks for investigating @jwoudenberg ❤️

@ayazhafiz do you think #7450 was the cause for the issue or just ended up revealing it?

[ayazhafiz]

ended up revealing it

…

On Sat, Jan 18, 2025 at 1:26 PM Anton-4 ***@***.***> wrote: Thanks for investigating @jwoudenberg <https://github.com/jwoudenberg> ❤️ @ayazhafiz <https://github.com/ayazhafiz> do you think #7450 <#7450> was the cause for the issue or just ended up revealing it? — Reply to this email directly, view it on GitHub <#7509 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6GL6XHQGPR4VC6TPYUSN32LKMFPAVCNFSM6AAAAABVDQNGSKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJZHAYTSOBRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jwoudenberg]

I probably misunderstand the point, but I can confirm it definitely worked before, that is my test suite ran and I've been using the package in projects.

Other information that maybe provides a clue or maybe doesn't: In the same commit that introduces the runtime error, there's also a compile-time oddity: I have to explicitly add an annotation to a helper let-function to get code to compile where I didn't before. The type-annotation alone makes the compiler error go away, I don't have to change the implementation.

[jwoudenberg]

I found that by replacing direct recursion with mutual recursion in two places I can work around the problem. Posting here in case it helps anyone else!