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?
[ Parent
| on HN ]
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).