roc/crates/compiler
Joshua Warner 20d092ea48
Remove indented-else syntax from the formatter
This is step 1 in removing the syntax all together. The formatter will now seemlessly migrate everyone to the usual if/then/else syntax. After everyone has had a chance to upgrade, we can then remove this from the parser (in a future PR).
2025-01-20 19:18:37 -08:00
..
alias_analysis Progress on updating entire compiler for snake_case 2025-01-05 03:48:03 -08:00
build correct error message 2025-01-07 16:32:16 +01:00
builtins Use parens, not WSA in tests, add docs linebreaks, factor calls into a var. 2025-01-20 10:58:44 +01:00
can with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
checkmate Progress on updating entire compiler for snake_case 2025-01-05 03:48:03 -08:00
checkmate_schema
collections Progress on updating entire compiler for snake_case 2025-01-05 03:48:03 -08:00
constrain Store lambda set variables as flex inference variables 2025-01-05 23:54:37 -05:00
debug_flags Restrict usages of type variables in non-generalized contexts 2025-01-02 14:26:37 -06:00
derive Fix broken ability implementation 2025-01-04 05:37:17 -08:00
derive_key Fix broken ability implementation 2025-01-04 05:37:17 -08:00
exhaustive
fmt Remove indented-else syntax from the formatter 2025-01-20 19:18:37 -08:00
gen_dev with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
gen_llvm with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
gen_wasm with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
ident
late_solve
load Merge pull request #7533 from smores56/simple-can-solo 2025-01-19 19:06:10 -08:00
load_internal Merge pull request #7533 from smores56/simple-can-solo 2025-01-19 19:06:10 -08:00
lower_params Restrict usages of type variables in non-generalized contexts 2025-01-02 14:26:37 -06:00
module with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
mono with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
parse Remove indented-else syntax from the formatter 2025-01-20 19:18:37 -08:00
problem Resolve TODO around handling non-plain strings 2025-01-11 20:24:34 -08:00
region
roc_target
serialize
solve with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
solve_problem Restrict usages of type variables in non-generalized contexts 2025-01-02 14:26:37 -06:00
solve_schema
test_derive Update derive tests 2025-01-05 07:34:53 -08:00
test_gen Use parens, not WSA in tests, add docs linebreaks, factor calls into a var. 2025-01-20 10:58:44 +01:00
test_mono update mono tests 2025-01-20 11:02:59 +01:00
test_mono_macros
test_solve_helpers
test_syntax Remove indented-else syntax from the formatter 2025-01-20 19:18:37 -08:00
types Fix failing tests, remove unnecessary NONE bitflag 2025-01-19 15:33:01 -08:00
uitest with_ascii_lowercased zig builtin 2025-01-20 10:58:41 +01:00
unify Merge branch 'main' into ayaz/error-on-invalid-generalized-types 2025-01-10 14:36:48 -05:00
work Move desugaring to new roc_can_solo crate 2025-01-19 07:16:43 -08:00
worker
DESIGN.md Remove backpassing 2025-01-01 17:44:56 -08:00
README.md

The Roc Compiler

For an overview of the design and architecture of the compiler, see DESIGN.md. If you want to dive into the implementation or get some tips on debugging the compiler, see below

Getting started with the code

The compiler contains a lot of code! If you're new to the project it can be hard to know where to start. It's useful to have some sort of "main entry point", or at least a "good place to start" for each of the main phases.

After you get into the details, you'll discover that some parts of the compiler have more than one entry point. And things can be interwoven together in subtle and complex ways, for reasons to do with performance, edge case handling, etc. But if this is "day one" for you, and you're just trying to get familiar with things, this should be "good enough".

The compiler is invoked from the CLI via build_file in cli/src/build.rs

Phase Entry point / main functions
Compiler entry point load/src/file.rs: load, load_and_monomorphize
Parse header parse/src/module.rs: parse_header
Parse definitions parse/src/module.rs: module_defs
Canonicalize can/src/def.rs: canonicalize_defs
Type check solve/src/module.rs: run_solve
Gather types to specialize mono/src/ir.rs: PartialProc::from_named_function
Solve specialized types mono/src/ir.rs: from_can, with_hole
Insert reference counting mono/src/ir.rs: Proc::insert_refcount_operations
Code gen (optimized but slow) gen_llvm/src/llvm/build.rs: build_procedures
Code gen (unoptimized but fast, CPU) gen_dev/src/object_builder.rs: build_module
Code gen (unoptimized but fast, Wasm) gen_wasm/src/lib.rs: build_module

For a more detailed understanding of the compilation phases, see the Phase, BuildTask, and Msg enums in load/src/file.rs.

Debugging the compiler

Please see the debug flags for information on how to ask the compiler to emit debug information during various stages of compilation.

There are some goals for more sophisticated debugging tools:

General Tips

Miscompilations

If you observe a miscomplication, you may first want to check the generated mono IR for your code - maybe there was a problem during specialization or layout generation. One way to do this is to add a test to test_mono/src/tests.rs and run the tests with cargo test -p test_mono; this will write the mono IR to a file.

Typechecking errors

First, try to minimize your reproduction into a test that fits in solve_expr.

Once you've done this, check out the ROC_PRINT_UNIFICATIONS debug flag. It will show you where type unification went right and wrong. This is usually enough to figure out a fix for the bug.

If that doesn't work and you know your error has something to do with ranks, you may want to instrument deep_copy_var_help in solve.

If that doesn't work, chatting on Zulip is always a good strategy.