-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: disabling display location section #2118
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like for this to be disabled on debug builds as well. Instead of changing the panic hook, I think we shouldn't panic at all when issuing compiler errors.
Yeah, I'm getting a panic on compilation errors in Noir with this. As this is a situation where the issue is bad user input, it shouldn't panic. |
as far as I understand, we are not panicking now, but returning an error:
the In the event of utilizing |
Co-authored-by: jfecher <jfecher11@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I compile a bad program such as
fn main(x: bool) {
assert(foo);
}
I now get the output
$ nargo prove
error: cannot find `foo` in this scope
┌─ /home/tom/Programming/noir/tmep/src/main.nr:2:12
│
2 │ assert(foo);
│ --- not found in this scope
warning: unused variable x
┌─ /home/tom/Programming/noir/tmep/src/main.nr:1:9
│
1 │ fn main(x: bool) {
│ - unused variable
Error:
0: Aborting due to 1 previous error
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⋮ 2 frames hidden ⋮
3: nargo_cli::cli::start_cli::ha2a4506e189093d5
at <unknown source file>:<unknown line>
4: std::sys_common::backtrace::__rust_begin_short_backtrace::h0afdd9622daa4648
at <unknown source file>:<unknown line>
5: std::rt::lang_start::{{closure}}::h7a1a28d32aaaecbb
at <unknown source file>:<unknown line>
6: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h072eb4cd8da964ba
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:286
7: std::panicking::try::do_call::h8eca204fe9266946
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483
8: std::panicking::try::h12574e1b7b2cbacb
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447
9: std::panic::catch_unwind::hf71522d4448329d6
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137
10: std::rt::lang_start_internal::{{closure}}::h65b66ac9bff580f8
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148
11: std::panicking::try::do_call::hfff61e33ca3db9f1
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483
12: std::panicking::try::he48c8ecead279cad
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447
13: std::panic::catch_unwind::hd510a26bfc950ccc
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137
14: std::rt::lang_start_internal::hc680b25eab888da9
at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148
15: main<unknown>
at <unknown source file>:<unknown line>
16: __libc_start_call_main<unknown>
at <unknown source file>:<unknown line>
17: __libc_start_main_alias_1<unknown>
at <unknown source file>:<unknown line>
18: _start<unknown>
at <unknown source file>:<unknown line>
I don't see how this is an improvement over the existing behaviour.
this output will be only with "RUST_BACKTRACE=1"
|
Is this happening because we're installing to the eyre-hook as well now? We should not print stack traces when issuing compiler errors under any circumstances, lets remove it. Many users may have |
locations in this case should be disabled specifically for EyreHook, the workaround is to write your own report handler without printing the location |
Can we revisit this PR? The |
Possibly relevant is the disabling section in the readme: https://github.com/eyre-rs/color-eyre#disabling-tracing-support |
I've tried disabling the feature, but it seems that because acvm-backend-barretenberg is enabled, it affects our crate |
Still getting some odd error formatting with this PR:
Looks like the If this is difficult to remove, wasn't there an alternative library to lyre? We could try swapping to that instead to see if it is easier to disable this Location information. |
there is a miette, but there is the same problem: zkat/miette#269 miette:
perhaps it would be easier to fork color_eyre? |
Looks like it may be printed by rust itself because we return a Result from main. Perhaps we should consider refactoring so that we do not do that? If we print out the errors directly, then set the exit code with std::process::exit, would this still work on wasm builds? CC @TomAFrench |
If we're doing this in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the exploration here! I think this is a good approach we've settled on. Let's just revert back to color-eyre if possible.
Pending re-review from @TomAFrench |
Will handle on Monday |
manually checked and it works
* master: feat(traits): Type checking for Trait impl method signatures (#2652) chore: split 9_conditional test case and remove 8_integration (#2751) chore(github): Add "Idea Action Plan" Issue template (#2736) feat(aztec-noir): abstract storage (#2750) feat: signed arithmetic (#2748) chore: encapsulate abstraction leaks from `bb` into new crate (#2747) feat: Variable liveness analysis for brillig (#2715) chore: noirjs integration testing (#2744) chore: Add rust-toolchain file & adapt nix for changes (#2686) chore: wrap backend info response in a struct instead of boxed closure (#2737) fix: check for literal overflows in expressions (#2742) fix: nightly js test (#2740) fix: keep the correct type for bitshift (#2739) chore: Make new daily nightly releases be pre-releases and non latest (#2735) chore: disabling display location section (#2118) chore: add a workflow that tracks acvm version for integration tests (#2700) feat: Save nightly build in github releases with date tags (#2416) chore: Add unified linting setup for JS code and enforce in CI (#2728)
Description
disabling display location section on release build
Problem
Resolves #2104
Summary
cargo fmt
on default settings.