Stop compilation on the first error, and highlight it first

[cunidev]

Highlighting the latest code syntax error makes it more difficult to find the line of code causing problems...

Example:

Class classname();
classname.doThis(); <--- # 1
classname.doThat();
classname.doThatAgain(); <--- this line is highlighted in case of error, instead of # 1

I don't know if I'm clear... Thanks

[matthijskooijman]

I guess the best solution would be to highlight all errors, and jump to / focus the first one? Agreed that the last error isn't typically the one to look at and the first error is.

[cunidev]

Yes, my solution was only if it wasn't possible to highlight all. Of course
all lines highlighted would be better.
Il 31/ago/2015 22:31, "Matthijs Kooijman" [email protected] ha
scritto:

I guess the best solution would be to highlight all errors, and jump to
/ focus the first one? Agreed that the last error isn't typically the one
to look at and the first error is.

—
Reply to this email directly or view it on GitHub
#3748 (comment).

[mikaelpatel]

A simple solution is to use the extra_flags variables in platform.txt and add the gcc compiler option -Wfatal-errors

This option causes the compiler to abort compilation on the first error occurred rather than trying to keep going and printing further error messages.

The platform variables to change are:
compiler.c.extra_flags=-Wfatal-errors
compiler.cpp.extra_flags=-Wfatal-errors

This could be nice for beginners.

Ref. 1. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

[cunidev]

Thanks for the answer. Would it be possible to suggest this changes via a
pull request then, or would there be any drawbacks? (There shouldn't be any
in my opinion)
Il 31/ago/2015 23:20, "Mikael Patel" [email protected] ha scritto:

A simple solution is to use the extra_flags variables in platform.txt and
add the gcc compiler option -Wfatal-errors

This option causes the compiler to abort compilation on the first error
occurred rather than trying to keep going and printing further error
messages.

The platform variables to change are:
compiler.c.extra_flags=-Wfatal-errors
compiler.cpp.extra_flags=-Wfatal-errors

This could be nice for beginners.

Ref. 1. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

—
Reply to this email directly or view it on GitHub
#3748 (comment).

[q2dg]

+1 for pull request. It's an obvious improvement

[matthijskooijman]

Having more than one error shown can make things more efficient, though, -Wfatal-errors means you can only look at and fix one error at a time (though that might be easiest for novice users, perhaps?).

Perhaps something to discuss on the mailing list?

[cunidev]

Well, as the code is read by the compiler from the first to the last line, it's not that useful IMHO to see all the errors, because they are usually caused by the first error (like in the first example). Otherwise, it would still be necessary to solve the first error first. Try to remove a simple semicolon: the compiler will probably highlight the last line of the sketch. Pretty useless, isn't it?
I'd insert -Wfatal-errors as default, and in case allow to disable it...

[shiftleftplusone]

I agree to matthijskooijman:
"
I guess the best solution would be to highlight all errors, and jump to / focus the first one? ...
"

Additionally, jumping to the related errors in the source code by double-click on either error listed in the debug window would be very helpful though.

[matthijskooijman]

Well, as the code is read by the compiler from the first to the last line, it's not that useful IMHO to see all the errors, because they are usually caused by the first error (like in the first example). Otherwise, it would still be necessary to solve the first error first. Try to remove a simple semicolon: the compiler will probably highlight the last line of the sketch.

That is true, but consider other errors too: a typo in function name, a wrong number of arguments to a function, etc. These will not break the syntax and usually not introduce any additional errors, making any errors beyond the first real errors too.

[shiftleftplusone]

so I'd suggest to implement the list-all-errors-and-at-double-click-then-jump-to-related-source-code-line feature

[Chris--A]

Jumping to a line on click seems like a valuable addition. I would probably find having only one error at a time very frustrating.

[NicoHood]

I also dont like a single error. But what about an option in preferences? Similar to the Warning setting you could stop on the first error here.

Jumping to the first error could be an idea though.

[lmihalkovic]

is there a sample sketch laying around somewhere that I could use to test the behavior in the way that you'd like it to work? (one of the difficulties is the n -> 1 aggregation of all .INOs but it just means more code... would be good if there was a sample with a single .ino, and the worst case scenario you can find where you'd still want this feature to work cleanly)

[lmihalkovic]

I was thinking about 2 panes in the console: 1) for the raw info as it exists now, and the second with a cleaned up list of errors. would that make sense or would you prefer to jump directly from the current raw output list?

alternatively it is also possible still have a separate list presentation, but available under QuickAccess via something like "errors". Meaning from the editor "CRTL+3" "err" will likely already display the list, then ARROW-UP/DOWN ENTER to go somewhere in the source code.

[lmihalkovic]

@mikaelpatel thank you kindly for taking the time to respond...

[lmihalkovic]

wrote the code, it is indeed helpful (have not settled on the final presentation though... so it is still time to express any views)

looks like the standard builder aborts when one file has any number of issues (am writing a replacement for arduino-builder.. will see what that one will do)

[lmihalkovic]

This is basically a few more lines of code/cleanup while doing what i suggest in #3771

[lmihalkovic]

testing bookmarking all errors in the editor (works for my compiler and for arduino-builder - I promise it's not a big deal to change the compiler class to collect all errors instead of bailing on first one - may I suggest that if you go down that path, you consider changing RunningException to become a simple RunningError pojo and no longer an Exception)

[per1234]

I don't understand this talk of the last error line being highlighted. I don't remember this ever being the case. The oldest IDE version I have installed is 1.0.3 and even that one jumps to and highlights the first error line. I also checked with 1.6.5-r5 and 1.6.4, which were the recent versions at the time of this report, and still the first error line was jumped to and highlighted.

The idea of jumping to the relevant line when you double click on the error message brought up by shiftleftplusone already has a dedicated issue report: #3383

So this issue should be focused solely on the idea of having the option to halt compilation on the first error. I agree this would be very helpful to beginners. Often they don't realize they need to scroll to the top of the console window to see the relevant error message so they are looking at whatever fragment of the end of the error output happens to be visible in the console window.

[matthijskooijman]

So this issue should be focused solely on the idea of having the option to halt compilation on the first error.

arduino-builder already stops at the first failed gcc command, so this would need some gcc option to stop at the first error. It seems -Wfatal-errors does exactly this. However, I'm not sure if adding this option unconditionally is a good idea. Whereas it might help novice users with simple sketches, it would greatly hinder more advanced users with big sketches and a lot of errors, having to recompile after fixing every one error really slows things down.

[tmdrake]

There should be an option not to stop on the first error... and jumping to that code. It reallys screws us advance user who may be changing the code while its compiling (and cant cancel)