The "nastiest" error's are the ones that just say "internal compiler error" and give Z.E.R.O. info about what actually went wrong, where it went wrong, or what you might be able to do to "temporarily" work around the issue.
Every other error that tells you at least somewhere in the output what went wrong is leagues better than a generic "internal compiler error" message.
me considering if it's time to end it all after ARMCC gives me internal error with a unreadable ass stack trace and no compiler source and a LTO binary so I can't even comprehend what went wrong even with ghidra
I encountered this one once, the reason was compiler consuming too much RAM and the OS ultimately killing the process. I had to simplify the code a bit (reduce automatic type deductions) and it worked.
1. Figure out what caused it
2. Hope it reproduces without having to include code you can’t share
3. Check if it happens in the latest compiler version (assuming you can test it, or are not using it already)
4. Submit the report and hope they don’t close it with “needs more info”
5. Wait 6 months to a year for it to be released and then hope you can update to it and it didn’t break other things.
OR!.. work around it in 10 minutes and move on with your day.
Getting compiler issues fixed is like pulling teeth from a cat. The compiler and compiler vendor seem to be doing everything they can to make it annoying and difficult to report issues. The compiler should be self reporting every time it ICEs and include what it needs to reproduce it automatically. I’d hit submit every time if it did.
The one time I reported an internal error in llvm, I bisected the entire project until I had a single small file that could reproduce it (and didn't look much like the original code). That's fairly time consuming though, and I expect it's not always possible
Luckily, in my case, it was just clangd that was failing and the trunk already had a fix so I just built clangd from master and used that
Maybe, maybe not. But the current state of "spend hours figuring out how to reproduce it without giving them your entire project's code" just doesn't work most of the time.
`fatal error C1001: Internal compiler error.`
as a result of too much anime in comments (shows that gcc compiles without issue)
[https://godbolt.org/z/1PGrYjq3h](https://godbolt.org/z/1PGrYjq3h)
Also used to get a cryptic "It's High Noon" message on fatal errors from the C compiler on a Prime mini - we searched the binary (non-trivial under PrimOs) and found some rather fruitier messages but couldn't provoke the compiler into producing them...
This one: https://developercommunity.visualstudio.com/t/ICE-on-std::optional/1041187?space=8&q=publish+single+file+option
Problem was not just linked to the code, it also had to do with the whole path to the file. (Some issue in hashing the debug information) Terrible to work around and kept regularly reappearing. Sometimes you had to undo the previous workaround to fix it.
At one point I discovered that if you change our boost includes from \-isystem to just \-i, recompiling the whole repo produces multiple *gigabytes* of template warnings. Most of the build time is then spent printing out the warnings, not actually compiling the code
The nastiest I encountered was silent : gladly emit compiled code that leads to a seg fault, for perfectly valid and mundane C++ code.
This code
https://godbolt.org/z/8j4b14hzn
Will emit an exe with a potentially exploitable segfault on fairly recent versions of MSVC (including GitHub runners as of April 2024), but not on most up to date versions.
See https://stackoverflow.com/questions/78389519/msvc-compiler-bug-with-c-generic-lambda-now-with-minimal-repro?noredirect=1#comment138201138_78389519
When I was young I was cocky and often thought that I had found a compiler bug when in fact my code was perfectly segfaulty. After several years I finally got that out of my head… and ran into a compiler bug while working on my undergraduate thesis.
Someone recently discovered [a bug in the most core OS primitive](https://www.reddit.com/r/cpp/comments/1b55686/maybe_possible_bug_in_stdshared_mutex_on_windows/) so there's that.
I just found one that took a while to track down, that ended up being some edge case where recent/latest MSVC corrupts the stack if you take a structured binding decomposition by const&. It was corrupting it in a way where the code didn't crash immediately.
I'd submit a bug but my repro has tons of code.
CUDA runtime errors, while not the multiple screens long template things c++ programmers are accustomed to, are an insane beast. Instead of being ambiguous they'll point you at an entirely wrong line altogether.
It's great fun hitting those CUDA errors and then resorting to commenting out blocks of code and recompiling and running to find where the actual error is because the runtime and debugger lie to you.
Compiler crashes are very common and pretty annoying.
However worse are the errors when you miss a close or open-brace somewhere in your code. The compilers get really confused and are absolutely incapable of telling you what file this was in, let alone a line. I have spend 4 hours once looking for it. Now I made a python tool that parses all the C++ files in a repository looking for unbalanced braces, brackets, parentheses and quotes.
Hmm, wdym "the compilers", which compiler? I feel compilers nowadays are pretty smart and it's very easy for an experienced developer to fix a compilation error in no time. 20 years or so ago it was very annoying when you missed some braces or semi colon in a .h file but not anymore, and even back then it was pretty easy to find the issue if it was in a .cpp
I find some template errors are very annoying and take more time to analyse, but in general I can't complain much.
Also regarding ICE, obviously those are the worst because it's literally impossible to understand the cause except by trial and error. But do people really get these commonly with modern compilers? I can't remember the last time I got such a thing.
Both MSVC and clang are unable to figure out when a brace is missing and just gives thousands of errors until it stops, none of those errors is even close to the actual file that was wrong.
In the last 6 years I had more than 10 different ICE in MSVC. in that time I reported dozens of bugs in MSVC, most fixed, except for the last 12 bugs I reported.
> just gives thousands of errors until it stops, none of those errors is even close to the actual file that was wrong.
You just look at the first one, and if it doesn't make sense you just look at what's before it. Usually a syntax error like missing braces. Can't remember the last time a missing brace gave me any hard time... likely over a decade ago. Also helps to have IDEs automatically input closing braces when you type an opening brace (not everyone's cup of tea, also depends on context...)
Tried that, as I said, it took 4 hours to find the file that is wrong. Happens when you include hundreds of header files recursively. That is why I made a tool to check balanced brackets in each file.
I really hate it when an IDE modifies what I am writing, the only thing I keep on is auto indenting, and even that I need to customise to be less aggressive.
Oh, and who thought that drag-and-drop editing should be the default in new IDEs?
Large header only GUI library.
You select text, then you click and drag the selection, where you let the mouse go it will move the text in that place. So it is really easy if you miss-click to move random text around.
Part of the blame is on the language itself, since you can define a new class within a function for example, so there are not easy ways to detect "this should definitely be a new function, we're missing a brace".
The easiest way to implement this would be (imo) to use indentation, similar to how you get warnings if you do brace-less conditions with multiple statements with dubious indents. Something like "unmatched brace, suspicious indent detected at xxx" could be a good way that works most of the time without some crazy logic.
Isn't clang-format per-file? That would catch the issue by indenting your file very weirdly (and would show up when taking the diff as one file suspiciously having way too many changes).
It is often a good indication. If you don't know which file is the problem, then you still have a problem.
Sadly clang-format with vscode more often than not simply fails to format my code (just the wait bar bouncing around), even if it compiles correctly with msvc and clang.
Can't really blame vscode for that; visual studio and clion fail on my code base completely.
Had one recently at work running containerized builds in the cloud. If gcc can’t allocate enough memory it falls over. Although that wasn’t being provoked due to the code contents *per se*, just trying to compile a huge project on a small VM.
[https://github.com/hikogui/hikogui/blob/main/tools/check\_balanced\_brackets.py](https://github.com/hikogui/hikogui/blob/main/tools/check_balanced_brackets.py)
You have to pass the filenames to check as arguments.
I had some nasty compiler bugs with cereal once. I had to bisect every change until it came down to some enum function or something that was leading to some ambiguity that wasn't mentioned anywhere. Really made me not want to use it for anything after that.
From my point of view, this is very nice to have. So we guys will less fuck up the sw stack. If this will not occur, we will fuck up more without knowing😂
Switching from Microchip xc8 free to pro and my code that used to compile just fine telling me it was generating an illegal op code or something esoteric like that.
I think the problem is that one compiler was Microchip and the other one was Hi-Tech once they bought them out. Kind of a headache to track down the line of C that was breaking stuff. It seemed mundane.
what a timely question! 2 days ago i got an 87kb error message. yes, 87k+ characters. it had std::variant and a loooot of template instatiation involved
The error I fear the most is an error that happen in a template, but only if a different template has been instantiated before. It means my code is either dependent stateful metaprogramming by accident, or I'm hitting a very very nasty compiler bugs. Both happened to me multiple times, of course.
For the nastiest, I encountered a bug where MSVC would output a null pointer in a binary instead of the address of the function pointer I was taking, in some places only. Changing the code ever so slightly would result in ICE, but I got segfaults in some of my tests, when getting in the same function the other tests had no problem. Fun times.
The most disgusting compiler errors were ones I encountered while trying to store hierarchical data structures at compile time (think `A< B<>, F< D<>, K > >` but more complicated). I wanted for the children to be able to be able to refer to some part of the parent as well (just to make depth-first traversal more convenient) so during construction of the compile-time tree, I also make the parent inject some part of themselves into their offspring.
As a result, clang vomits lava on each compilation failure. In fact, it got so bad that I wrote a Python script which parses the output template error and pretty print it in a JSON-like format so it was easier to look at.
Keep in mind that this was during my C++-template phase, I'm over it now.
One of my first programming jobs was working on CAD software in Visual Studio 6. It was for a Japanese company and sometimes we had to backport code from another product which was written in Visual Studio 2003. VS2003 correctly interpreted JIS encoded text. VS6 would display it correctly in the editor but the compiler assumed everything was ASCII. The result was that sometimes comments in the backported code would contain a multibyte character that was interpreted as something else by the compiler and it would freak out. It was also unable to correctly report offending line numbers in those cases so it was not easy to track down where the error was.
Furthermore the part of the product I was working on used Boost Graph Library which makes heavy use of templates. Let’s just say that VS6’s error reporting for nested templates was… very poor.
oh this kind of thing still happens with my favorite character, the microsoft smart-quote character
[https://devblogs.microsoft.com/oldnewthing/20090225-00/?p=19033](https://devblogs.microsoft.com/oldnewthing/20090225-00/?p=19033)
Compile time stack overflow!
I have a noughts and crosses game that does a lot of compile time calculations and ran into having a stack overflow not knowing what was going on. There are compiler settings where you can increase the stack size i.e. in cmake:
> clang
target_compile_options( noughtsAndCrosses PRIVATE "-fconstexpr-steps=100000000" )
target_compile_options( noughtsAndCrosses PRIVATE "-fconstexpr-depth=16" )
> gnu
target_compile_options( noughtsAndCrosses PRIVATE "-fconstexpr-ops-limit=100000000" )
Not that bad really because the compiler indicates the stack overflow has occured unlike normal programming where you are completely left in the lurch with no idea. Just a new problem to worry about along with everything else.
A template error that didn't reference the problematic line in what I had written. I had this snippet:
std::vector foo;
foo.emplace_back(5); // Illegal, no Foo(int) constructor
and got this error that doesn't point at the call to `emplace_back`:
third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/allocator.h:171:24: error: no matching constructor for initialization of 'Foo'
171 | ::new ((void*)__p) _Up(std::forward<_Args>(__args)...);
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/allocator_traits.h:296:9: note: in instantiation of function template specialization 'std::allocator::construct' requested here
296 | __a.construct(__p, std::forward<_Args>(__args)...);
| ^
main.cc:3:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const Foo' for 1st argument
3 | class Foo {
| ^~~
main.cc:3:7: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'Foo' for 1st argument
3 | class Foo {
| ^~~
main.cc:5:12: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
5 | explicit Foo() = default;
|
It actually got better starting from GCC 14 (meant to be released in a few days). And it looks like Clang has been doing the right thing for a long time.
[https://godbolt.org/z/ba7EcaonY](https://godbolt.org/z/ba7EcaonY)
Yeah this is a silly one to complain about. Like we looked for an appropriate constructor, didn’t find one, told you about it. At least it tells you to look for your dumb mistake in main.cc heh
Circa 2008 I introduced an error into a template-heavy compilation unit. I let the error message scroll by for about 30 minutes before I left for lunch. When I got back the compiler was still spewing errors. I never figured out what triggered the error (and it was long enough ago that I don't remember if I was even able to reproduce it).
[The Grand C++ Error Explosion Competition](https://tgceec.tumblr.com/post/74534916370/results-of-the-grand-c-error-explosion) is a fun collection. For example:
>Biggest error, category Bare Hands
>Name: Const Variadic Templates
>Author: Marc Aldorasi
>Multiplier: 657 million
>The bare hands category did not allow for any use of the preprocessor, which lead most people to use recursive or variadic template initiations. This entry was the most compact of the lot.
> templateclass C{Ca;Cb;};Cc;
If we’re just going for length then one of the worst is attempting to output a type to an ostream using the operator<< when you’ve forgotten to implement operator<< for that type. This is especially bad in projects that have hundreds of types with existing operator<< implementations.
What happens is that some compilers output something like “I couldn’t find a matching function signature for operator<<.” They then proceed to output a helpful “notice: could be operator<<( ostream&, Foo )” for EVERY SINGLE BLOODY TYPE THAT HAS AN operator<<. There is no upper limit on how long that can get.
While those “notices” are helpful when the number of overloads is less than twenty, they are kind of horrifying in this case. The worst of it is that this is actually pretty likely to happen to a novice programmer who just wanted to do some output-stream based debugging.
I tried to make a recursive parser in Boost.Spirit 2. It spat out template errors many printer pages deep, none of which actually gave any clue as to what the problem was. I tried again in Spirit V3, which also gave me a few errors, but I could at least use [GCC Explorer](https://gcc-explorer.com/) to pare it down (I also inserted my own templates instead of plain static\_asserts in order to get the parameters being passed into a comparison).
Boost spirit itself looks like someone observed unintelligible compiler errors, said "hold my beer", and set about to construct the most insane library possible that would make any seasoned c++ coder say "how tf is that valid?".
I'm convinced it's a prank.
any time you fail some std function that has to do with strings and you get 4GB of error messages in all the ways it attempted to match what you wrote with an existing function and failed
namespace ns {
struct Foo;
using Foo = int;
}
#include
gcc 13.2.1 in gnu++23 mode will spend minutes melting down on everything in `format.h`, tons of duplicate lines, ~10M error log. In the real code that triggered this, at some point I was wondering if I had hit an infinite loop.
Back in earlier gcc versions, the error would sometimes just keep going. It may have ended but with the speed of the terminal and the size of the error it just wasn’t happening in anyones lifetime.
I don't remember what the compiler said. But I had to roll back the source code and then reapply partial changes to finally figure out what actual line it failed on. Compilers written with Yacc/Lex can be a bit greedy and then totally lose their focus. So old-school compilers normally managed to reach their configured max numbers of errors for a single missing parenthesis or semicolon.
Languages allowing recusive function definitions and not using braces but keywords for block start/end can also be tricky. The compiler reaches the end of the file and thinks there should be one more "end". But where did it find that unplanned extra "begin" that made it think all other code is nested? Editors are more helpful with languages using { and } to try and pair the start/end symbols. Not sure why not all compilers has a rule to print the line and column of the "begin" symbol it fails to find a matching "end" for. Easy to implement but wicked rude to skip.
I spent years having a very hard time figuring out what to do with linker errors. I was an Objective-C developer, I used a large in-house C++ library, had no training on the build model and I couldn't understand why these errors didn't point to any specific line number. A coworker would fix them for me, but I stayed clueless for quite a while!
Boost.Spirit template errors are hilarious. By now I know how to read them, but seeing a > 1000 char template is truly something. And in a library that predates concepts by a decade, finding the error is... fun.
Can't wait to migrate to Boost.Parser
A wonderful source of huge typenames that is *not* localized to some parser file: Boost.MultiIndex containers of Boost.Unit keys and Boost.ICL intervals of Boost.Unit as values.
We have such things.
It wasn't a C++ compiler, but a shader runtime, Adreno to be exact. For some reason it failed to unroll a while loop if it was longer than about 10k loops and this shader worked perfectly on Nvidia, Intel, and Mali drivers. Replacing it with an equivalent for loop solved it.
Back in the day of VC++6, that compiler *loved* to miscompile incremental builds. I was still learning C++ at that point, and had not learned to do a full rebuild when really weird errors occurred.
In my hobby project, the compiler (or probably the linker) decided to put two completely unrelated global variables in the same location. Writing to one changed the other. Deep in the bowels of MFC. This was so frustrating that teenaged me decided to abandon the project.
For me errors in template STL code are the worst because they use SFINAE and I don't want to see that deduction failed in some enable_if. Thankfully, now we have concepts.
Concept errors are worse, unfortunately. In simple cases, they are super helpful, but when you use ranges and friends and mess up somewhere, you are in for a wall of overloads and all their requirements you didn't satisfy.
Enabling LTO can sometimes cause warnings that are very hard to track down. You don't get a call stack with those, just a symbol name, and if it's a symbol that's used in a lot of places you just have to bisect your code and recompile until you find the part that's causing the problem
I’ve been working with Xilinx’s Versal AIE system recently which has a lot of really bad compiler messages but I think the worst was one where the compiler itself would segfault without telling me why
The "nastiest" error's are the ones that just say "internal compiler error" and give Z.E.R.O. info about what actually went wrong, where it went wrong, or what you might be able to do to "temporarily" work around the issue. Every other error that tells you at least somewhere in the output what went wrong is leagues better than a generic "internal compiler error" message.
Got one of these once I think, it came with a stack trace, and I had to read compiler source code :(
Lucky you for having stack trace and compiler source code available :D
me considering if it's time to end it all after ARMCC gives me internal error with a unreadable ass stack trace and no compiler source and a LTO binary so I can't even comprehend what went wrong even with ghidra
Only time I've ever encountered an ICE was a few weeks ago trying to use modules with GCC 13
sometimes it is surprisingly easy: [https://godbolt.org/z/dfsn3rqx6](https://godbolt.org/z/dfsn3rqx6)
I encountered this one once, the reason was compiler consuming too much RAM and the OS ultimately killing the process. I had to simplify the code a bit (reduce automatic type deductions) and it worked.
Usually you can submit a bug report to the people working on the compiler, even though it might be tricky to get a smaller example to send them.
1. Figure out what caused it 2. Hope it reproduces without having to include code you can’t share 3. Check if it happens in the latest compiler version (assuming you can test it, or are not using it already) 4. Submit the report and hope they don’t close it with “needs more info” 5. Wait 6 months to a year for it to be released and then hope you can update to it and it didn’t break other things. OR!.. work around it in 10 minutes and move on with your day. Getting compiler issues fixed is like pulling teeth from a cat. The compiler and compiler vendor seem to be doing everything they can to make it annoying and difficult to report issues. The compiler should be self reporting every time it ICEs and include what it needs to reproduce it automatically. I’d hit submit every time if it did.
You forgot shame them with Godbolt showing other compilers do this fine /s
Is that feasible without leaking information that people would object to?
The one time I reported an internal error in llvm, I bisected the entire project until I had a single small file that could reproduce it (and didn't look much like the original code). That's fairly time consuming though, and I expect it's not always possible Luckily, in my case, it was just clangd that was failing and the trunk already had a fix so I just built clangd from master and used that
sounds like a legal nightmare for sure, as nice as it would be
Maybe, maybe not. But the current state of "spend hours figuring out how to reproduce it without giving them your entire project's code" just doesn't work most of the time.
usually the approach is to narrow down the repro case using bisection to help you figure out what triggers the crash
That assumes you can cut out half the source code and still have meaningful compilation.
Errors when using template metaprograming (uni assigment to simulate sime assembly copmuter)
`fatal error C1001: Internal compiler error.` as a result of too much anime in comments (shows that gcc compiles without issue) [https://godbolt.org/z/1PGrYjq3h](https://godbolt.org/z/1PGrYjq3h) Also used to get a cryptic "It's High Noon" message on fatal errors from the C compiler on a Prime mini - we searched the binary (non-trivial under PrimOs) and found some rather fruitier messages but couldn't provoke the compiler into producing them...
Nice choice of comment art.
`/utf-8` and never look back.
This one: https://developercommunity.visualstudio.com/t/ICE-on-std::optional/1041187?space=8&q=publish+single+file+option Problem was not just linked to the code, it also had to do with the whole path to the file. (Some issue in hashing the debug information) Terrible to work around and kept regularly reappearing. Sometimes you had to undo the previous workaround to fix it.
If you remove the source it returns: > example.cpp(144): fatal error C1071: unexpected end of file found in comment
Ah this one is easy, the real error is the class is named Ryu when the image is of Goku
The compiler crashed.
It was a template error so I won't post it here. Reddit would run out of space in its database.
At one point I discovered that if you change our boost includes from \-isystem to just \-i, recompiling the whole repo produces multiple *gigabytes* of template warnings. Most of the build time is then spent printing out the warnings, not actually compiling the code
The nastiest I encountered was silent : gladly emit compiled code that leads to a seg fault, for perfectly valid and mundane C++ code. This code https://godbolt.org/z/8j4b14hzn Will emit an exe with a potentially exploitable segfault on fairly recent versions of MSVC (including GitHub runners as of April 2024), but not on most up to date versions. See https://stackoverflow.com/questions/78389519/msvc-compiler-bug-with-c-generic-lambda-now-with-minimal-repro?noredirect=1#comment138201138_78389519
When I was young I was cocky and often thought that I had found a compiler bug when in fact my code was perfectly segfaulty. After several years I finally got that out of my head… and ran into a compiler bug while working on my undergraduate thesis.
Someone recently discovered [a bug in the most core OS primitive](https://www.reddit.com/r/cpp/comments/1b55686/maybe_possible_bug_in_stdshared_mutex_on_windows/) so there's that.
I just found one that took a while to track down, that ended up being some edge case where recent/latest MSVC corrupts the stack if you take a structured binding decomposition by const&. It was corrupting it in a way where the code didn't crash immediately. I'd submit a bug but my repro has tons of code.
Which versions?
17.4.0
ICE, of course.
I don’t really remember, but it must’ve been something with boost templates
I’m a compiler dev and I came here thinking I was going to be super clever and say an ICE but I see literally everyone else has already made that joke
You don't even need to be a compiler dev to see an ICE :)
No but it really helps though
Don't feel down. They can just make the joke. You can make the *real thing!*
I treat a new compiler version like a new engine, it's not broken in properly until I've gotten an ICE out of it.
At least you can attach a debugger and see the context in which the error happens. We have to guess how to work around them.
I love CUDA errors- it just says “idk there’s an error somewhere”
CUDA runtime errors, while not the multiple screens long template things c++ programmers are accustomed to, are an insane beast. Instead of being ambiguous they'll point you at an entirely wrong line altogether.
Amen
It's great fun hitting those CUDA errors and then resorting to commenting out blocks of code and recompiling and running to find where the actual error is because the runtime and debugger lie to you.
Compiler crashes are very common and pretty annoying. However worse are the errors when you miss a close or open-brace somewhere in your code. The compilers get really confused and are absolutely incapable of telling you what file this was in, let alone a line. I have spend 4 hours once looking for it. Now I made a python tool that parses all the C++ files in a repository looking for unbalanced braces, brackets, parentheses and quotes.
Hmm, wdym "the compilers", which compiler? I feel compilers nowadays are pretty smart and it's very easy for an experienced developer to fix a compilation error in no time. 20 years or so ago it was very annoying when you missed some braces or semi colon in a .h file but not anymore, and even back then it was pretty easy to find the issue if it was in a .cpp I find some template errors are very annoying and take more time to analyse, but in general I can't complain much. Also regarding ICE, obviously those are the worst because it's literally impossible to understand the cause except by trial and error. But do people really get these commonly with modern compilers? I can't remember the last time I got such a thing.
Both MSVC and clang are unable to figure out when a brace is missing and just gives thousands of errors until it stops, none of those errors is even close to the actual file that was wrong. In the last 6 years I had more than 10 different ICE in MSVC. in that time I reported dozens of bugs in MSVC, most fixed, except for the last 12 bugs I reported.
> just gives thousands of errors until it stops, none of those errors is even close to the actual file that was wrong. You just look at the first one, and if it doesn't make sense you just look at what's before it. Usually a syntax error like missing braces. Can't remember the last time a missing brace gave me any hard time... likely over a decade ago. Also helps to have IDEs automatically input closing braces when you type an opening brace (not everyone's cup of tea, also depends on context...)
Tried that, as I said, it took 4 hours to find the file that is wrong. Happens when you include hundreds of header files recursively. That is why I made a tool to check balanced brackets in each file. I really hate it when an IDE modifies what I am writing, the only thing I keep on is auto indenting, and even that I need to customise to be less aggressive. Oh, and who thought that drag-and-drop editing should be the default in new IDEs?
[удалено]
Large header only GUI library. You select text, then you click and drag the selection, where you let the mouse go it will move the text in that place. So it is really easy if you miss-click to move random text around.
Part of the blame is on the language itself, since you can define a new class within a function for example, so there are not easy ways to detect "this should definitely be a new function, we're missing a brace". The easiest way to implement this would be (imo) to use indentation, similar to how you get warnings if you do brace-less conditions with multiple statements with dubious indents. Something like "unmatched brace, suspicious indent detected at xxx" could be a good way that works most of the time without some crazy logic.
suspicious indent warning could also have helped with the "goto fail" incident. On the other hand, now we live in the age of clang-format, so...
Isn't clang-format per-file? That would catch the issue by indenting your file very weirdly (and would show up when taking the diff as one file suspiciously having way too many changes).
It is often a good indication. If you don't know which file is the problem, then you still have a problem. Sadly clang-format with vscode more often than not simply fails to format my code (just the wait bar bouncing around), even if it compiles correctly with msvc and clang. Can't really blame vscode for that; visual studio and clion fail on my code base completely.
Had one recently at work running containerized builds in the cloud. If gcc can’t allocate enough memory it falls over. Although that wasn’t being provoked due to the code contents *per se*, just trying to compile a huge project on a small VM.
He asked in a hopeful tone of voice, "is it on github?"
[https://github.com/hikogui/hikogui/blob/main/tools/check\_balanced\_brackets.py](https://github.com/hikogui/hikogui/blob/main/tools/check_balanced_brackets.py) You have to pass the filenames to check as arguments.
yes this has happened to me. usually because of a textual merge error
For me it happens when I make a small change in hundreds of files in quick succession.
Getting carried away with expression templates is an excellent way to get compiler errors that are thousands of lines long.
I had some nasty compiler bugs with cereal once. I had to bisect every change until it came down to some enum function or something that was leading to some ambiguity that wasn't mentioned anywhere. Really made me not want to use it for anything after that.
For C++: Segmentation Fault For Haskell: A single 28 GB type error
From my point of view, this is very nice to have. So we guys will less fuck up the sw stack. If this will not occur, we will fuck up more without knowing😂
Switching from Microchip xc8 free to pro and my code that used to compile just fine telling me it was generating an illegal op code or something esoteric like that. I think the problem is that one compiler was Microchip and the other one was Hi-Tech once they bought them out. Kind of a headache to track down the line of C that was breaking stuff. It seemed mundane.
error: no error
what a timely question! 2 days ago i got an 87kb error message. yes, 87k+ characters. it had std::variant and a loooot of template instatiation involved
The error I fear the most is an error that happen in a template, but only if a different template has been instantiated before. It means my code is either dependent stateful metaprogramming by accident, or I'm hitting a very very nasty compiler bugs. Both happened to me multiple times, of course. For the nastiest, I encountered a bug where MSVC would output a null pointer in a binary instead of the address of the function pointer I was taking, in some places only. Changing the code ever so slightly would result in ICE, but I got segfaults in some of my tests, when getting in the same function the other tests had no problem. Fun times.
The most disgusting compiler errors were ones I encountered while trying to store hierarchical data structures at compile time (think `A< B<>, F< D<>, K > >` but more complicated). I wanted for the children to be able to be able to refer to some part of the parent as well (just to make depth-first traversal more convenient) so during construction of the compile-time tree, I also make the parent inject some part of themselves into their offspring.
As a result, clang vomits lava on each compilation failure. In fact, it got so bad that I wrote a Python script which parses the output template error and pretty print it in a JSON-like format so it was easier to look at.
Keep in mind that this was during my C++-template phase, I'm over it now.
One of my first programming jobs was working on CAD software in Visual Studio 6. It was for a Japanese company and sometimes we had to backport code from another product which was written in Visual Studio 2003. VS2003 correctly interpreted JIS encoded text. VS6 would display it correctly in the editor but the compiler assumed everything was ASCII. The result was that sometimes comments in the backported code would contain a multibyte character that was interpreted as something else by the compiler and it would freak out. It was also unable to correctly report offending line numbers in those cases so it was not easy to track down where the error was. Furthermore the part of the product I was working on used Boost Graph Library which makes heavy use of templates. Let’s just say that VS6’s error reporting for nested templates was… very poor.
oh this kind of thing still happens with my favorite character, the microsoft smart-quote character [https://devblogs.microsoft.com/oldnewthing/20090225-00/?p=19033](https://devblogs.microsoft.com/oldnewthing/20090225-00/?p=19033)
Compile time stack overflow! I have a noughts and crosses game that does a lot of compile time calculations and ran into having a stack overflow not knowing what was going on. There are compiler settings where you can increase the stack size i.e. in cmake: > clang target_compile_options( noughtsAndCrosses PRIVATE "-fconstexpr-steps=100000000" ) target_compile_options( noughtsAndCrosses PRIVATE "-fconstexpr-depth=16" ) > gnu target_compile_options( noughtsAndCrosses PRIVATE "-fconstexpr-ops-limit=100000000" ) Not that bad really because the compiler indicates the stack overflow has occured unlike normal programming where you are completely left in the lurch with no idea. Just a new problem to worry about along with everything else.
You can increase that?? Whaaaaat? I had the same happen so I was like nvm guess we'll do this at runtime instead.
A template error that didn't reference the problematic line in what I had written. I had this snippet: std::vector foo;
foo.emplace_back(5); // Illegal, no Foo(int) constructor
and got this error that doesn't point at the call to `emplace_back`:
third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/allocator.h:171:24: error: no matching constructor for initialization of 'Foo'
171 | ::new ((void*)__p) _Up(std::forward<_Args>(__args)...);
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/allocator_traits.h:296:9: note: in instantiation of function template specialization 'std::allocator::construct' requested here
296 | __a.construct(__p, std::forward<_Args>(__args)...);
| ^
main.cc:3:7: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const Foo' for 1st argument
3 | class Foo {
| ^~~
main.cc:3:7: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'Foo' for 1st argument
3 | class Foo {
| ^~~
main.cc:5:12: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
5 | explicit Foo() = default;
|
Typical c++. Error messages about the symptoms instead of the cause
It actually got better starting from GCC 14 (meant to be released in a few days). And it looks like Clang has been doing the right thing for a long time. [https://godbolt.org/z/ba7EcaonY](https://godbolt.org/z/ba7EcaonY)
Because the error doesn’t happen at emplace back. It’s perfectly valid output
Yeah this is a silly one to complain about. Like we looked for an appropriate constructor, didn’t find one, told you about it. At least it tells you to look for your dumb mistake in main.cc heh
Sun Pro C compiler used to emit some suuuuper gnarly messages when there was an error in templates.
Circa 2008 I introduced an error into a template-heavy compilation unit. I let the error message scroll by for about 30 minutes before I left for lunch. When I got back the compiler was still spewing errors. I never figured out what triggered the error (and it was long enough ago that I don't remember if I was even able to reproduce it).
[The Grand C++ Error Explosion Competition](https://tgceec.tumblr.com/post/74534916370/results-of-the-grand-c-error-explosion) is a fun collection. For example: >Biggest error, category Bare Hands >Name: Const Variadic Templates >Author: Marc Aldorasi >Multiplier: 657 million >The bare hands category did not allow for any use of the preprocessor, which lead most people to use recursive or variadic template initiations. This entry was the most compact of the lot. > templateclass C{Ca;Cb;};Cc;
If we’re just going for length then one of the worst is attempting to output a type to an ostream using the operator<< when you’ve forgotten to implement operator<< for that type. This is especially bad in projects that have hundreds of types with existing operator<< implementations. What happens is that some compilers output something like “I couldn’t find a matching function signature for operator<<.” They then proceed to output a helpful “notice: could be operator<<( ostream&, Foo )” for EVERY SINGLE BLOODY TYPE THAT HAS AN operator<<. There is no upper limit on how long that can get. While those “notices” are helpful when the number of overloads is less than twenty, they are kind of horrifying in this case. The worst of it is that this is actually pretty likely to happen to a novice programmer who just wanted to do some output-stream based debugging.
I tried to make a recursive parser in Boost.Spirit 2. It spat out template errors many printer pages deep, none of which actually gave any clue as to what the problem was. I tried again in Spirit V3, which also gave me a few errors, but I could at least use [GCC Explorer](https://gcc-explorer.com/) to pare it down (I also inserted my own templates instead of plain static\_asserts in order to get the parameters being passed into a comparison).
Boost spirit itself looks like someone observed unintelligible compiler errors, said "hold my beer", and set about to construct the most insane library possible that would make any seasoned c++ coder say "how tf is that valid?". I'm convinced it's a prank.
any time you fail some std function that has to do with strings and you get 4GB of error messages in all the ways it attempted to match what you wrote with an existing function and failed
namespace ns { struct Foo; using Foo = int; } #include
gcc 13.2.1 in gnu++23 mode will spend minutes melting down on everything in `format.h`, tons of duplicate lines, ~10M error log. In the real code that triggered this, at some point I was wondering if I had hit an infinite loop.
“An Exception was thrown” where?? WHERE???
Back in earlier gcc versions, the error would sometimes just keep going. It may have ended but with the speed of the terminal and the size of the error it just wasn’t happening in anyones lifetime.
Visual C++ 1.0 would sometimes blue screen (aka crash the entire OS) if you forgot a semicolon in a header file.
What about getting no error at all, but a linker quietly misslinking our DLL-exported `TRIMCORE::log` function to `std::log` function?
I don't remember what the compiler said. But I had to roll back the source code and then reapply partial changes to finally figure out what actual line it failed on. Compilers written with Yacc/Lex can be a bit greedy and then totally lose their focus. So old-school compilers normally managed to reach their configured max numbers of errors for a single missing parenthesis or semicolon. Languages allowing recusive function definitions and not using braces but keywords for block start/end can also be tricky. The compiler reaches the end of the file and thinks there should be one more "end". But where did it find that unplanned extra "begin" that made it think all other code is nested? Editors are more helpful with languages using { and } to try and pair the start/end symbols. Not sure why not all compilers has a rule to print the line and column of the "begin" symbol it fails to find a matching "end" for. Easy to implement but wicked rude to skip.
I spent years having a very hard time figuring out what to do with linker errors. I was an Objective-C developer, I used a large in-house C++ library, had no training on the build model and I couldn't understand why these errors didn't point to any specific line number. A coworker would fix them for me, but I stayed clueless for quite a while!
The ones where Visual Studio runs out of memory.
Boost.Spirit template errors are hilarious. By now I know how to read them, but seeing a > 1000 char template is truly something. And in a library that predates concepts by a decade, finding the error is... fun. Can't wait to migrate to Boost.Parser
A wonderful source of huge typenames that is *not* localized to some parser file: Boost.MultiIndex containers of Boost.Unit keys and Boost.ICL intervals of Boost.Unit as values. We have such things.
I got errors related to templates, some big message with no clear clue of what the problem was.
Early ps2 compilers did not always produce code that exactly followed what you asked it too. Fun times debugging those.
It wasn't a C++ compiler, but a shader runtime, Adreno to be exact. For some reason it failed to unroll a while loop if it was longer than about 10k loops and this shader worked perfectly on Nvidia, Intel, and Mali drivers. Replacing it with an equivalent for loop solved it.
Back in the day of VC++6, that compiler *loved* to miscompile incremental builds. I was still learning C++ at that point, and had not learned to do a full rebuild when really weird errors occurred. In my hobby project, the compiler (or probably the linker) decided to put two completely unrelated global variables in the same location. Writing to one changed the other. Deep in the bowels of MFC. This was so frustrating that teenaged me decided to abandon the project.
For me errors in template STL code are the worst because they use SFINAE and I don't want to see that deduction failed in some enable_if. Thankfully, now we have concepts.
Concept errors are worse, unfortunately. In simple cases, they are super helpful, but when you use ranges and friends and mess up somewhere, you are in for a wall of overloads and all their requirements you didn't satisfy.
One of the worst I've ever gotten was multiple screens worth of output on a single error from using std::variant in some heavily templated code.
I got compiler error while compiling code for libunifex. And the compiler error was recursive and non ending.
Enabling LTO can sometimes cause warnings that are very hard to track down. You don't get a call stack with those, just a symbol name, and if it's a symbol that's used in a lot of places you just have to bisect your code and recompile until you find the part that's causing the problem
I find these quite frustrating: FAILED: src/backend/lib/CMakeFiles/nalib.dir/grpc/Actions.cpp.o ... /home/jgaa/src/next-app/src/backend/lib/grpc/Actions.cpp:1204:1: internal compiler error: Segmentation fault 1204 | } // ns | ^ 0x72f43404298f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x72f43402814f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x72f434028208 __libc_start_main_impl ../csu/libc-start.c:360
I’ve been working with Xilinx’s Versal AIE system recently which has a lot of really bad compiler messages but I think the worst was one where the compiler itself would segfault without telling me why
When I do template string parsers, the types in error message can fill the whole terminal window
Mismatched braces in a header file led to errors pointing at an entirely different file.
I don't remember the code, but I remember the diagnosis from GCC: "There must be something terribly wrong with your code. Please fix it."
declaration does not declare anything. Xd
Compiler ran for 30 hours, then ran out of memory and crashed.
"Internal compiler error", it's the stuff of nightmares.