Debugging Spadec
Temporarily using a local compiler
You can use --override-compiler to build your project using a local clone of the spade compiler instead of the one specified in the swim.toml.
Figuring Out What is Going On
Tracing
The parser and type inferer has internal tracing that can be used to track down bugs.
Parser tracing is only available in tests and can be turned on by setting SPADE_TRACE_PARSER
Type inference tracing is available everywhere, and can be turned on by setting SPADE_TRACE_TYPEINFERENCE to the fully qualified path of a unit for for which the trace should be printed.
Swim Logging
For debugging swim, you can set SWIM_LOG=<level> where level is debug, trace, info, warn, or error to get more information about what it is doing.
Debugging and profiling
If you experience a crash or freeze of the compiler, it can be useful to run it through gdb. For that, you can use
Running with --debug-spadec runs the compiler through gdb
Running with --wrap-spadec runs the compiler through a custom command, for example, --wrap-spadec gdb runs gdb spadec <args> instead of spadec. Since gdb requires a --args argument to pass arguments to the program being debugged, you also need to use --wrapper-args="--args" with gdb
Profiling
--wrap-spadec is also very useful for profiling. Typically, this involves running something like
swim --wrap-spadec <your wrapper program> --wrapper-args <arg1> --wrapper-args <arg2> ... <your normal swim command>Here it can also be useful to add --spadec-debug and/or --rustflags in order to get things like debug symbols.
See swim --help for more debug flags
Faster iteration times
Running swim with --spadec-debug builds the compiler in debug mode which includes debug symbols and results in faster compiler build times which makes iterating on compiler changes easier