Skip to content
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

Add a flag to forc to reverse the order of printed errors #3860

Closed
kayagokalp opened this issue Jan 23, 2023 · 6 comments · Fixed by #4142
Closed

Add a flag to forc to reverse the order of printed errors #3860

kayagokalp opened this issue Jan 23, 2023 · 6 comments · Fixed by #4142
Assignees
Labels
forc forc-pkg Everything related to the `forc-pkg` crate. good first issue Good for newcomers

Comments

@kayagokalp
Copy link
Member

Requested by @nfurfaro in a recent sway sync. Since most of the time, lots of errors propagates from the first error (meaning that once the first error is fixed, all of them goes away) it would make sense to be able to revert the order so that users do not need to scroll.

@kayagokalp kayagokalp added good first issue Good for newcomers forc forc-pkg Everything related to the `forc-pkg` crate. labels Jan 23, 2023
@nfurfaro
Copy link
Contributor

Thinking about this a bit more, I think the first thing to check is that given libraries b, c & d which all depend on library a, if there's a compile error in a, forc should not attempt to build the dependent libs. This would go a long way to resolving my issue and deals with the root more directly.

@otrho
Copy link
Contributor

otrho commented Jan 23, 2023

This is a bit of a tricky UI question. Compilers historically have tried to continue and gather errors greedily to try and improve the edit-compile-run loop, by not insisting that each error must be fixed one at a time. This is especially important for long compile times on big projects. Just because a has an error doesn't mean b will have a problem, or that b's error is related. OTOH pages of cascading errors due to a single typo is a pain in the neck.

Reversing the order of the errors is an interesting idea though -- I don't think I've ever seen it before (at least outside of an IDE). Not needing to scroll to see the first error would be useful.

@nfurfaro
Copy link
Contributor

Honestly, it would save a bunch of time spent trying to find the top of the most recent errors, as the first one is alway the one I want to fix .

@gr00vytvniks
Copy link
Contributor

This seems like a challenge I'm willing to take on if nobody else has been assigned

@gr00vytvniks
Copy link
Contributor

I'm having trouble finding where we emit errors. Is this an issue with forc or forc-pkg, or is it somewhere else in the Sway repo?

@kayagokalp
Copy link
Member Author

@gr00vytvniks

Hmm, I would look into places like:

sway/forc-pkg/src/pkg.rs

Lines 2567 to 2570 in 1d31ff6

let fail = |warnings, errors| {
print_on_failure(terse_mode, warnings, errors);
bail!("Failed to compile {}", pkg.name);
};

Which seems to use print_on_failure from forc-util which can be seen below:

sway/forc-util/src/lib.rs

Lines 233 to 246 in 1d31ff6

pub fn print_on_failure(terse_mode: bool, warnings: &[CompileWarning], errors: &[CompileError]) {
let e_len = errors.len();
if !terse_mode {
warnings.iter().for_each(format_warning);
errors.iter().for_each(format_err);
}
println_red_err(&format!(
" Aborting due to {} {}.",
e_len,
if e_len > 1 { "errors" } else { "error" }
));
}

So this might be as simple as iterating over the errors and warnings in backwards if a flag is present in the linked section above.

eureka-cpu pushed a commit that referenced this issue Jun 21, 2023
Adds the ability to reverse errors and warnings in either the command line or via a BuildProfile.

closes #3860
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
forc forc-pkg Everything related to the `forc-pkg` crate. good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants