fix: Display causes but not stack trace in CLI error report

[aakoshh]

Description

Problem*

Resolves something I noticed while reviewing #7578

Summary*

Some of the CLI used eprintln!("{report}") to display errors, while others use eprintln!("{report:?}").
Using the former with eyre means we only see the outermost .context(msg), which can hide a lot useful details about the original error. See https://docs.rs/eyre/latest/eyre/struct.Report.html#display-representations

Additional Context

For example if I point the profiler to a non-existing artifact, all we see it this:

$ ./target/debug/noir-profiler opcodes --artifact-path  ./test_programs/execution_success/blah.json --output test.json
Error reading program from file

With eprintln!("{report:?}"); we get the nested contextual messages like a stack, and the stack trace:

$ ...
Error reading program from file

Caused by:
    No such file or directory (os error 2)

Location:
    tooling/profiler/src/cli/opcodes_flamegraph_cmd.rs:46:47

With eprintln!("{report:#}") we get a more compact output that omits source code locations (which could be considered an implementation detail that should not concern the user, but I'd only recommend it if we used .context more vigorously to provide a human readable trace):

$ ...
Error reading program from file: No such file or directory (os error 2)

Since noir-inspector and noir-execute use :? I thought we can stick to that for now.

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[vezenovm]

I had removed eprintln!("{report:?}"); for eprintln!("{report}"); in the profiler as I didn't want to expose internal details to the user for CLI errors.

For example now in nargo let's say I forget to include a Prover.toml:

Cannot find input file '/mnt/user-data/maxim/noir/test_programs/execution_success/1_mul/Prover.toml'

Location:
    tooling/nargo_cli/src/cli/mod.rs:137:5

I don't think we should be showing the CLI locations to the user. I find it actually more confusing.

Perhaps we can have something similar to RUST_BACKTRACE=1 for debugging mode. However, this is normally used for Rust panics. So we can run nargo with this flag already if we have an internal panic, and for Noir execution, we already provide full call stacks.

[aakoshh]

I had removed eprintln!("{report:?}"); for eprintln!("{report}"); in the profiler as I didn't want to expose internal details to the user for CLI errors.

Okay, like I mentioned in the description we can use eprintln!("{report:#}") to display as much of the context of what went wrong as possible, including the original error message, and all the contextual messages that got attached to it. I'll change the value accordingly to all CLIs. Like I said it's just less likely to tell us exactly what you want to know, unless we consistently provide good error messages and contexts. For example some std::io::Error will say that "file not found" but won't say which one, unless the thing that called it used .context or .wrap_err to give hints, or maybe .with_context to even attach the path, or if we used a custom error message which captured the arguments we had problem with. Even then, if somebody used .context on top of our custom error, the message of the .context would be the only one shown with {report} which is usually very frustrating.

[aakoshh]

I suppose we could have an env var to influence the report format, like if RUST_BACKTRACE itself is set we can use debug format to help in cases where the error is nondescript.

[vezenovm]

eprintln!("{report:#}")

Yeah I think this is better than {report:?}.

Like I said it's just less likely to tell us exactly what you want to know, unless we consistently provide good error messages and contexts.

I understand your desire for more information in the error reports. I do think for public facing binaries we should consistently provide good error messages and contexts through our noirc_errors reporter.

This method is used in nargo_cli for reporting execution failures and I recently started using it in the profiler as well when I switched {report:?} to {report}.

[aakoshh]

Yes, for the errors generated about Noir that's fantastic 👍 This is more for just the bits and bobs that can go wrong in the CLI, opening and decoding files, etc.

[vezenovm]

Yes, for the errors generated about Noir that's fantastic 👍 This is more for just the bits and bobs that can go wrong in the CLI, opening and decoding files, etc.

Yeah I understand, I just didn't want to muddle user errors. If {report:#} is insufficient I think we should look at an env var to influence extra debug info.