Roc crashed: Builtin.U8 does not implement len() · bugs

I've encountered the following behavior, and before opening an issue I would like to learn what I can do to debug this issue myself.

app [main!] { pf: platform "https://github.com/lukewilliamboswell/roc-platform-template-zig/releases/download/0.6/2BfGn4M9uWJNhDVeMghGeXNVDFijMfPsmmVeo6M4QjKX.tar.zst" }

import pf.Stdout
print = Stdout.line!
main! = |_| {
  testVal = \\if(equals(1, 333), {ref}, "nothing")
  testVal->tokenize->Str.inspect->print

  Ok({})
}

tokenize: Str => Try([Eof, LParen, RParen, StringLit], [UnexpectedToken({message: Str})])
tokenize = |str| {
  bytes = str.to_utf8()
  if bytes.is_empty() {
    return Ok(Eof())
  }
  # bad region wtih type inference side effects for `bytes`
  _first_byte = match bytes.first() {
    Err(ListWasEmpty) => {return Ok(Eof())}
    Ok(b) => b
  }
  # /bad region
  _ascii_bytes = bytes->take_while(|_| True)
  Err(UnexpectedToken({message: "unexpected token"}))
}

take_while: List(a), (a -> Bool) => List(a)
take_while = |list, predicate| {
  var $new = List.with_capacity(list.len())
  for item in list {
    if !predicate(item) {
      return $new
    }
    $new = $new.append(item)
  }
  $new
}

Roc crashed: Builtin.Num.U8 does not implement len

However, when I comment out the match (“bad region”), I get the expected output

Try.Err(UnexpectedToken({ message: "unexpected token" }))

Now how would I go about debugging this? Or: how do you do it? I could think of:

Anton (Feb 20 2026 at 09:26):

Hi @Lukas Juhrich,
Based on my first impression I believe this is a bug that AI can handle, I use claude code with opus 4.6 thinking set to high. I recommend running zig build minici to run all tests after the fix is done. The difficult part lies in assessing the quality of the fix. You can check who wrote the code that surrounds the fix and ask them to review it.

Lukas Juhrich (Feb 20 2026 at 09:55):

That would be nice if all I was interested in is a fix, but I would specifically like to do things myself to learn about the compiler. So if we pretend that this fix would be too difficult for AI – what would the strategy then be? Reading the code and tests to understand the pipeline, working test-driven and mainly working with zig build minici?

Anton (Feb 20 2026 at 10:08):

I think in this case we either pass the bug on to whomever has the most expertise with that part of the code or ask that person some questions and ask them to review the PR. My belief is that there is no generally applicable strategy in that case, you need to have a deep understanding of how things fit together, what the intended functionality is, and all the trade-offs involved.

Luke Boswell (Feb 20 2026 at 12:28):

I would try and reproduce in a snapshot test. zig build snapshot -- path/to/snapshot.md

At first glance it looks either like some kind of type checking issue, or a bug in the interpreter (there are many of these).

So if we make a snapshot test and it repros then we can narrow it down to the stages type checking or earlier and we will also have good human readable IRs to look at.

If it doesnt repro there it is most likely in the interpeter, and for that you can use the trace-eval flag maybe, or good old print debugging... which is much quicker when you have agents to assist :sweat_smile:

Aside if you just want to rebuild roc and not all the tools it is much quicker to do zig build roc

Luke Boswell (Feb 20 2026 at 12:31):

Actually... we already know it type checks from roc check ... so I would say it's very likely in the interpeter.

Lukas Juhrich (Feb 20 2026 at 19:33):

btw, I miswrote earlier, when I said roc build takes that long, I did indeed mean zig build roc :)

Stream: bugs