Compilation Report

Execution Report

Peak Memory Sample

Hmm, forcing the user to pass around another piece of compiler state is a little sad. I'd like to avoid this if possible but would need to think more on this.

The set of root files could be tracked by FileManager so we'd need less things to pass around... though at that point maybe FileManager would be doing more just than a single thing.

I'm thinking that there's enough information for what we want inside of the Context struct, following this down we can get the ModuleData for a particular crate.

By reading the ModuleData for a particular crate we can get a tree of all the modules within a particular crate. Working down from the root we can then use logic similar to find_module in order to get all of the FileIds connected to this crate.

We should then be able to generate this list after the fact rather than needing to pass it around externally to the compiler.

Note that this method will mean that we ignore any warnings outside of the current crate as opposed to the current workspace. This seems to be closer to what we want imo as it will avoid a workspace library from having its warnings emitted many times (this also matches up with cargo behaviour).

We could also track this a little more explicitly inside of the compiler state but the above is a "zero footprint" solution.

Edit: agreed that it would be best to keep FileManager "pure" and avoid it knowing about this.

Sounds good, I'll do what you say in the first comment.

I was thinking that eventually it would be nice for the compiler to be able to compile crates modularly. It's a bit strange that we read all files of all packages and all dependencies in one go. Ideally we'd process a package by reading its files, compiling it, then moving to dependent packages, even being able to parallelize things... though I know that would be a huge refactor, but in the way we'd get "for free" errors and warnings grouped by package.

Almost there! In compile_cmd and debug_cmd there's no Context so I don't know where to get the files from... Those files end up calling compile_program that returns CompilationResult<CompiledProgram>, maybe that type (CompiledProgram) could hold that, or maybe a tuple could be returned... but I think it would make the code messier again.

We can filter the returned warnings inside of the compiler before we pass it back up to nargo_cli though, no? Is there a reason why we need to do this externally?

Is there a reason why we need to do this externally?

The main reason is that for LSP we'd still want to show warnings in crates that are open in the UI but are not the main crate. Though I guess not doing would be fine too...

It worked! And for some reason it works well in LSP too, maybe the code there is slightly different, or maybe all crates are checked, not sure.

Execution Memory Report

Compilation Memory Report

I'm getting zero warnings being thrown in aztec-packages when using this PR despite there definitely being warnings that should be thrown.

Good catch, I might have changed something in the end that broke it. Now it's fixed.