Hacker News Reader

Comment by fivea | Hacker News Reader

> Intellij idea has endless "good code red" problems, it doesn't detect all compile problems,

Doesn't this just means that IntelliJ, being an independent implementation, flags problems that a compiler frontend doesn't, and vice-versa?

That's hardly a problem, isn't it? I mean, sometimes even compilers that serve as reference implementations fail to properly support some language constructs. Case in point, look at how GCC handled C++11, and how some features were only supported a couple of years after the standard was approved.

https://gcc.gnu.org/projects/cxx-status.html

> it still can't expand macros properly and autocomplete does not work at all with more advanced libraries.

Arguably, IntelliJ (or any IDE) shouldn't expand macros at all, and "more advanced" is codeword for "uses obscure features in non-trivial ways". Those are hardly problems.

View on HN

> Doesn't this just means that IntelliJ, being an independent implementation, flags problems that a compiler frontend doesn't, and vice-versa?

No, it often flags perfectly correct (compiling and working) code. Search for "good code red" on their bugtracker - this is going on for years. Many of those problems are because Intellij type inference infers a wrong type, then it can't resolve a method or field because it's looking it up in the wrong place. Or it misses the stuff expanded from a procedural derive macro.

The fundamental problem is, in order to make it work correctly they have to reimplement the whole compiler frontend, which is a very ambitious goal, and they likely don't have resources to do that for the many languages that Idea wants to support.

> Arguably, IntelliJ (or any IDE) shouldn't expand macros at all, and "more advanced" is codeword for "uses obscure features in non-trivial ways". Those are hardly problems.

Macros and metaprogramming are not obscure features - those are the core features that often make basic stuff work like serialization, database access, command line argument parsing or data formatting. While the libraries might be sometimes internally complex, they are often way easier to use than the counterparts in languages with no such support.

> No, it often flags perfectly correct (compiling and working) code.

"Compiling and working code" does not mean it's valid or acceptable code. Implementations can and often are buggy, or push implementation-defined behavior which is unacceptable. This code should be flagged appropriately. Case in point, C++11 support in GCC 4.8, and how "compiling and working code" in GCC4 broke horribly in subsequent releases.

> Search for "good code red" on their bugtracker - this is going on for years.

I fail to see how this is a good or reasonable test. A cursory search shows up only indexing problems, fixed by invalidating the cache, which bear no resemblance with language support.

Do you actually have any concrete example?

> Compiling and working code" does not mean it's valid or acceptable code.

In safe Rust and Scala it means it is valid, modulo bugs in the compiler, which are rare. Also I'm really talking about code that is obviously ok - e.g. there exists a function on given type, yet idea fails to see it.

> do you actually have any concrete example?

In both of my Rust projects, which are pretty tiny (<5k loc) there are a few instances of good code red issues or fragments where the type inference gave up (no error flagged, but also no autocomplete). Will report those.

I reported plenty of such issues earlier to the Scala plugin, and got tired a bit.

Reply on news.ycombinator.com