News for hackers. Stuff that matters.
Re:Results of the Grand C++ Error Explosion Competition (2014) by tester756 on Monday May 06, 2024 @03:31PM (#40278592)
But with this approach you arent able to provide e.g intellisense or other IDE hints for valid things within this node, right?
Re:Results of the Grand C++ Error Explosion Competition (2014) by WalterBright on Monday May 06, 2024 @04:02PM (#40278876)
A hint can be provided where the original error is diagnosed. I doubt hints on cascaded errors would be of any use.
Re:Results of the Grand C++ Error Explosion Competition (2014) by tester756 on Monday May 06, 2024 @04:26PM (#40279102)
if you have function like

"public intd Test() { ... typing new line }"

then you will not provide hints when writing that new line due to "intd" being invalid type?

Re:Results of the Grand C++ Error Explosion Competition (2014) by WalterBright on Monday May 06, 2024 @05:01PM (#40279479)
A function's declaration is not affected by its body, so that shouldn't be a problem.
Re:Results of the Grand C++ Error Explosion Competition (2014) by tnh on Monday May 06, 2024 @06:38PM (#40280306)
Things within the node are fine because errors propagate upwards. The problem is things like:

    Foo getFoo(int);
    getFoo().???; // want code completion!
`getFoo()` is missing an argument, but you still want to complete Foo's members. If you type `getFoo().getBar()` you want go-to-definition to work on `getBar`.

In clang, we use heuristics to preserve the type in high-confidence cases. (here overload resolution for `getFoo` failed, but there was only one candidate function). This means you can get cascading errors in those cases (but often that's a good thing, especially in an IDE - tradeoffs).