This is absolutely my biggest complaint about Rust. (https://github.com/rust-lang/rust/issues/27189). I’ve literally seen the compiler hallucinate hundreds of errors due to a minor syntax error in one file.
I can see that this may be useful in some cases like CI, but for interactive use cases I don’t want to see anything that isn’t for sure an error. Especially when that pushes the actual error a thousand lines up my terminal scrollback.
Personally I think trying to recover from a syntax error or such and keep parsing is something of a lost cause, but the people who use IDE-driven workflows keep disagreeing.
For some things I think it makes sense, like for syntax highlighting or maybe batch work like CI runs. But even for error squiggles in an IDE I don’t want my whole file to turn red because of one hallucinated error.
Oddly my (generally an IDE user, but not someone who really has gotten far into C++) reaction is that it’s very weird that you’d ever get to this point. In other languages, as soon as you type the first const book& it will show an error, and you probably won’t complete the function. Hovering over that parameter will offer an autocomplete to import something.
It yells at the line I’m changing, sometimes it marks the entire rest of the file red because a brace is missing or something. But it still mostly works better than what this article describes.
C++ is infamous for this (especially with templates, which are duck typed, and so the error is actually ‘this template argument does not implement this method’ but the printed error is 20-deep template instantiations with a cryptic error: concepts help here). Part of the problem is using a pen abstraction that resembles a piece of paper to read them. IDEs that can incrementally expand the error are a lot more readable.
Sometimes students on Linux will say, “I can’t see the first error message because my terminal’s scrollback buffer isn’t big enough.”
I like how Plan 9’s terminal did it: as I recall, it would scroll only until the first line of output was at the top, and then one could page down. Once you’ve used it, it makes so much sense!
This is a great rule … except for errors related to using C++ templates. Clang’s first errors usually point to the template’s source code and are pretty opaque unless you know that code. The rule of thumb I’ve developed is to look for & read the last error that starts with “in instantiation of function template…”, which is almost always at the line in my code where the error is.
C++ error messages are so much better than they were 20 years ago, but there’s still progress to be made with template errors. (Same is true of Nim errors involving macros.) I recognize it’s difficult for the compiler to report a clean error message when your source code has been manipulated beforehand.
And, in the worst case, it’s actually one or two instantiations in: you’ve done something based on a caller’s template argument that should be supported but your subsequent call doesn’t handle that case. Adding concepts helps make these readable, but concepts are not checked at template definition time and so this kind of thing may not be caught.
This is absolutely my biggest complaint about Rust. (https://github.com/rust-lang/rust/issues/27189). I’ve literally seen the compiler hallucinate hundreds of errors due to a minor syntax error in one file.
I can see that this may be useful in some cases like CI, but for interactive use cases I don’t want to see anything that isn’t for sure an error. Especially when that pushes the actual error a thousand lines up my terminal scrollback.
Personally I think trying to recover from a syntax error or such and keep parsing is something of a lost cause, but the people who use IDE-driven workflows keep disagreeing.
For some things I think it makes sense, like for syntax highlighting or maybe batch work like CI runs. But even for error squiggles in an IDE I don’t want my whole file to turn red because of one hallucinated error.
Oddly my (generally an IDE user, but not someone who really has gotten far into C++) reaction is that it’s very weird that you’d ever get to this point. In other languages, as soon as you type the first
const book&it will show an error, and you probably won’t complete the function. Hovering over that parameter will offer an autocomplete to import something.What about when you modify existing code?
It yells at the line I’m changing, sometimes it marks the entire rest of the file red because a brace is missing or something. But it still mostly works better than what this article describes.
The solution: don’t use the raw output of the compiler but a tool which shows you the relevant errors first.
See bacon: https://dystroy.org/bacon/
C++ is infamous for this (especially with templates, which are duck typed, and so the error is actually ‘this template argument does not implement this method’ but the printed error is 20-deep template instantiations with a cryptic error: concepts help here). Part of the problem is using a pen abstraction that resembles a piece of paper to read them. IDEs that can incrementally expand the error are a lot more readable.
I like how Plan 9’s terminal did it: as I recall, it would scroll only until the first line of output was at the top, and then one could page down. Once you’ve used it, it makes so much sense!
This is a great rule … except for errors related to using C++ templates. Clang’s first errors usually point to the template’s source code and are pretty opaque unless you know that code. The rule of thumb I’ve developed is to look for & read the last error that starts with “in instantiation of function template…”, which is almost always at the line in my code where the error is.
C++ error messages are so much better than they were 20 years ago, but there’s still progress to be made with template errors. (Same is true of Nim errors involving macros.) I recognize it’s difficult for the compiler to report a clean error message when your source code has been manipulated beforehand.
And, in the worst case, it’s actually one or two instantiations in: you’ve done something based on a caller’s template argument that should be supported but your subsequent call doesn’t handle that case. Adding concepts helps make these readable, but concepts are not checked at template definition time and so this kind of thing may not be caught.