It doesn’t invalidate your experience, it’s just a funny bug.
Internal compiler errors do happen from time to time. They're annoying but usually easy to work around. I've had projects where I just cannot use rust-analyze because it just never finishes. It just eats RAM without accomplishing anything.
Looking on the code example they provided [1], the comments is literally an anime character. Is he Naruto?
namespace StreetFighter {
class Ryu
This happens daily on my Intel MBP in Xcode. In only a ~15k LoC small app, 99% Swift. I’ve had to break up several functions into smaller ones purely because the compiler chokes so easily. They actually have a dedicated error message to the tune of “couldn’t figure out types here, could you break this function up please?”.
But yeah, outside of that I’ve never seen it happen in major languages using major language tooling. Never even saw it in 5 million+ line C/C++/.NET CLR mixed codebases.
C++ is complex enough that the IDE can't really parse much of the program's code in any useful fashion. You're lucky if it can get the right type hints and jump to definition. And even the latter may not be complete.
Contrast with e.g. Java, which makes it easy for the IDEs to get the full picture.
We're talking about C++ and Rust here, so I don't know why you bring up Java. If parsing Rust was as easy as parsing Java you would not see me complaining about it.
I brought up Java as an example of what it means for the IDE parsing to work and be useful.
I don't know what's going on in the Rust world, but in C++ world, even the good ol' Visual C++ (2017, 2019), when it crashes (which it does surprisingly often on my work's codebase), it doesn't lose anything other than maybe unsaved edits. It's annoying, sure, but 30 seconds later it's back to where it was before the crash.
Also, a not working parser is not a trivial inconvenience. It just means the tool doesn't work. From the POV of wanting to use advanced functionality that relies on parsing the code, it doesn't matter whether the tool aborts its execution so it doesn't crash, or has to be disabled because it doesn't abort its execution and just crashes. The end result is the same: I can't use the advanced functionality.
>Also, a not working parser is not a trivial inconvenience. [...] The end result is the same: I can't use the advanced functionality.
Yeah. Now compare "the IDE is just working as a glorified text editor" to what I'm describing above.
However.
That sounds to me less like an IDE problem, and more like a Linux problem. Specifically, the problem with the... unique way a typical Linux system handles OOM state, i.e. by suddenly curling into a ball and becoming completely unresponsive until you power-cycle it. I've hit that a couple times in the past, and my solutions were, in order:
- Monitoring the memory usage and killing the offending process (a graph database runtime) before it OOMs the system;
- After becoming tired of the constant vigilance, quadrupling the amount of RAM available in the OS; (yes, this is why people overprovision their machines relative to what naive economists or operations people may think..)
- Changing the job, and switching to working on Windows; WSL may not be 100% like a real Linux, but it inherits sane OOM handling from its host platform.
I'm sure there is a way in Linux to set a memory quota for the offending IDE process. This would hopefully reduce your problem to the more benign (if annoying) case I described earlier.
While I agree that Linux sucks at handling this particular situation, my point was about Rust's complexity. Normally, when you're using C/++ dependencies the IDE doesn't need to inspect the internals of the libraries to figure out how to parse dependent code. And, it's also true that rust-analyze doesn't know how to stop trying. It will parse what you give it, even if it kills your machine.
edit: mind, in the same code base (10M+ loc), Visual Studio would crash while attempting to initialize Intellisense.