Repository navigation
"limitSymbolsToIncludedHeaders" Settings for IntelliSense #1699
Description
Hi,
in c_cpp_properties.json there is an option to show all kind of symbols (i.e. not limited to the included headers) for the Tag Parser, but apparently this setting does not influence the default IntelliSense engine.
At least I could not invoke the autocompletion on a class-member as long as I did not include the respective header. As soon as I did, IntelliSense worked like a charm. It works in Tag Parser mode too, but this is not a real solution. So is there any setting which enables the behaviour I am looking for or is this a limitation of the current IntelliSense Engine I have to live with?
In case this is unexpected behaviour and the current implementation should already be able to do this by default, I can provide a code example.
--
OS: Ubuntu 17.04 64bit
Code: 1.21.1 Stable
Extension: 0.16-insiders
Activity
bobbrow commentedon Mar 19, 2018
That setting can't apply to the default IntelliSense engine because it acts like a compiler and it would be way too slow to force include all of your headers for every code file you open up in the editor. I don't know of a scenario where you wouldn't want to add the
#include <foo>at the top of your code file for types that you want to be visible for that file. Perhaps you can help me understand where that might be useful?cylonid commentedon Mar 19, 2018
Bob Brown (@bobbrow) I stumbled over this on the occasion of a global object instance (for non-globals you are right of course, you would have to include it anyway). The fun thing is, IntelliSense actually works for the global variable itself, but stops working for its class members as long as the respective headers are not included.
bobbrow commentedon Mar 19, 2018
This is probably because we hadn't finished autocomplete yet. In 0.15.0, only member list is using the new engine. Everything else (including global variables) uses the old engine (Tag Parser). In 0.16.0, autocomplete is finished and you will not get suggestions for your global variables unless you've included the declaration.
cylonid commentedon Mar 19, 2018
I further eloborated on the behaviour in terms of globals and found out that it's quite sophisticated already. The problem I am having is due to a class forward declaration in our framework where IntelliSense would need a proper #include to fully work.
A.h
So here in A.h we have a pointer to an instance of B, but only a forward declaration of class B. The include is in the implementation file.
A.cpp
main.cpp
Define global variable "a" in main.cpp..
test.cpp
Try to access the global variable in another file, e.g. test.cpp. If one wrote
#include "B.h"in A.h, it would work out of the box.bobbrow commentedon Apr 16, 2018
But test.cpp won't compile if B.h is not included, right? I'm still unclear as to why you would expect IntelliSense to know about B's members if the declaration of B is missing.
cylonid commentedon Apr 16, 2018
Yes, you have to include it, otherwise you get incomplete type errors upon compilation.
Above all, I was expecting this because I am used to have settings for this behaviour from other editors/IDEs. This is just a habit I guess, but I consider the experience to be more smooth if the auto-completion just works out of the box and I can think of including things later. But it's more of a nice-to-have feature, not a deal breaker.
bobbrow commentedon Apr 16, 2018
I see. I can talk to the owners of the IntelliSense engine, but I suspect that they wouldn't be open to this idea since the focus has always been "correctness." The philosophy is: If you can't compile the file with the suggestions we're giving you, then we're probably not suggesting the right things.
sean-mcmanus commentedon Apr 16, 2018
Bob Brown (@bobbrow) We could do what typescript does and add the required includePaths to make it correct/compile, but implementing this in a way that doesn't annoy people (by adding undesired #include) would be tricky.