roc-lang/roc

Summary Importing a type module brings its main type into scope automatically: import pf.Elem exposing [foo, bar] # Elem, foo, and bar are all in scope Writing import pf.Elem exposing [Elem] is common, especially in generated code. This issue originally proposed treating it as a redundant-expose warning with a formatter autofix. Discussion on Zulip (#ideas > Make import pf.Elem exposing [Elem] a warning) changed direction, so it should be a compile error instead. Design direction Items in an exposing list are always looked up inside the imported module. exposing [foo] means Elem.foo. By the same rule, exposing [Elem] means Elem.Elem, not "the main type again." Nested types may share their parent's name. Elem.Elem is silly but allowed. So the same spelling can refer to a different type, and we shouldn't quietly treat it as a no-op. For import M exposing [X] where M is a type module and X has the same name as the import: Case Result M.X does not exist Error. Elem is already in sco

Summary Use milliseconds consistently for completed timing rows in CLI timing breakdowns. Currently, each duration independently switches units. This makes a slow phase such as 10.7s easy to miss among nearby values such as 30ms, because the suffixes look similar when scanning the output: ✓ Body Graph Setup 30ms ✓ Body Traversal + Binding 10.7s ✓ Body Type Graph 0ms ✓ Body Call Dispatch 0ms The reporter has two rendering modes: Interactive TTY output commits completed rows while later phases are still running, so it cannot choose a common unit based on durations it does not know yet. Non-interactive --timings output prints the complete breakdown at the end. Choosing one fixed unit avoids different behavior between these modes and does not require buffering, predicting later durations, or rewriting committed terminal rows. Proposed behavior Render every completed phase and subphase duration in milliseconds, regardless of its len

Goal Track the remaining builtin work for the Zig compiler. Everything previously listed here that has landed has been removed. See the edit history for the full original checklist. Source of truth: src/build/roc/Builtin.roc, plus src/builtins/*.zig, src/base/LowLevel.zig, src/canonicalize/BuiltinLowLevel.zig, the backends, and src/eval/interpreter.zig. A row is done when the builtin is declared in Builtin.roc, lowered/implemented, supported on every backend and the interpreter, and covered by focused tests. Each item below is labelled: Accepted: the API existed in the old compiler, or follows an established pattern in the current builtins. It needs implementation, not discussion. Needs design: the shape is not settled. Discuss in the linked issue before implementing. API guidance: modern syntax (Try(ok, [Err, ..]), snake_case, where [a.method : ...]), module-specific functions (F64.ln, not Num.log), and one "pit of success" way to do each thing. Prefer Iter over per-collection conve

-- TYPE MISMATCH --------------------------------- This is not a record, so it does not have any fields to access: ┌─ examples/command.roc:21:2 │ 21 │ Cmd.new("env") │ ^^^^^^^^^^^^^^ It is: Cmd But I need a record with a clear_envs field. Here I typed: Cmd.new("env") .clear_envs .env("FOO", "BAR") ... Instead of the correct: Cmd.new("env") .clear_envs() .env("FOO", "BAR") The error message is making a very different assumption about the cause.

Instead of Num.to_str(a) you can now do a.to_str() . The error message should point the user to this new way: -- DOES NOT EXIST -------------------------------- Num.to_str does not exist. ┌─ examples/command.roc:35:32 │ 35 │ Stdout.line!("Exit code: ${Num.to_str(exit_code)}")? │ ^^^^^^^^^^