Similar to how the extension C/C++ Clang supports code completion, wouldn't this be within the scope of this extension?

Is this being worked on? this issue is relevant to https://github.com/Microsoft/vscode-cpptools/issues/180 though.
@sridmad Any status on this? Haven't heard much regarding auto-complete since April. Perhaps #180 is a suitable path to choose until the auto-complete feature is more finalized?
@sean-mcmanus @pieandcakes Anything in the roadmap? :)
Yes, the IntelliSense engine will enable a better autocomplete (code completion) experience. It is being actively worked on now. It was delayed for a few months by work being done in Visual Studio 2017 (and other factors).
@sean-mcmanus Nice to hear :) Looking forward to improvements on this already excellent extension!
Code completion and Intellisense don't work what so ever in VSCode.. literally like it isn't even there.
What plugin do you guys recommend using while this feature is not mature enough in vscode-cpptools?
@bootsector I have no clue but I'am about to get rid of VSCode in my C projects. I just wrote a console app that builds and runs correctly but no output is shown in terminal and exits with code 0.. Like wtf? I put it in CodeBlocks, ran like a charm. That's so depressing..
Yeah, I wanted to get rid of Eclipse CDT for my C projects too, but I think I will have to stick with it a little more then...
I'm also still facing an issue where my programs compile and run correctly but VSCode is telling me none of my header files are found. Highlighted red. But everything works. Still prints errors in terminal. Lol it needs polishing.
@KeplerIO Can you file an issue about your output problem? We currently don't support the in VSCode terminal but you should be able to get the output in a separate terminal window.
@pieandcakes Hey man, do you know how I could rig it up to open a CMD window when I run my C programs then?
@KeplerIO should be "externalConsole": true.
@KeplerIO Do you have the IntelliSenseEngine set to Default? Have you setup up your includePath and defines to match your compiler in c_cpp_properties.json? Autocomplete currently uses the browse.path setting to locate symbols.
Is this close to being released?
In the meantime, is it possible to use both this extension and the C/C++ Clang extension at the same time to get the best of both worlds?
We released support for member list autocomplete in version 0.12.0. Add "C_Cpp.intelliSenseEngine": "Default" to your settings.json to try it out.
Autocomplete for the remaining scopes is coming later.
Do you have an idea of when code completion for non-member variables (ie local variables) will be implemented?
@rdlaner We don't have any ETA yet. The "quickSuggestions" which shows a list of variables available at the current scope when typing an identifier is implemented but it has issues with performance (i.e. slowness).
I think this is working now. Using version 0.12.2.

@csholmq, I also am able to complete a pointer to a data structure, however, I am still not able to complete the name of the local variable itself. It would be nice if the auto-completion would prioritize local variables in the selection list.
See the below screenshots:
Unsuccessful completion of local variable name:
Successful local variable pointer dereference:
@rdlaner when we get the extension fast enough to list local and global variables we will turn it on and resolve this issue.
@rdlaner True. In my case my pointer was named p so it made auto completion trivial :p
@bobbrow is there a public roadmap for these implementations? A list of blocking issues? Or at least more information on the status of the local parsing (completion/code navigation)?
@gureito There's no public (or private) roadmap for implementing code completion for locals. The work hasn't been scheduled to a milestone yet. The blocking issue is performance -- we just have to investigate/fix it, but we've been busy with higher priority issues (e.g. symbol parsing performance). After we ship our January update, we'll evaluate what the next priority is for February. Code navigation using the IntelliSense engine is a different feature.
@bobbrow what is keeping local/global completion slow?
The code that gets the list of variables that are valid in the current cursor position.
I don't think I made myself clear. For instance, the python extension seems to handle globals and locals extremely well. Is there something about C/C++ that is holding this extension back?
@tristan957 We share code to compute this from VS 2017, but there are differences that cause our version to be slower that we need to investigate still. Our team decided to just ship the feature with scoped completion and we only spent a small amount of time investigating the global/local completion before it was decided to just shelve it for later. The complaints about this have started to bubble up recently, so we plan to revisit this for the March update after we've fixed various known crashes and update our IntelliSense parser.
Sounds good. Thank you for the information.
We just posted an insider release with the finished auto-complete implementation. If you want to get an early preview, you can install the VSIX that matches your OS and tell us what you think.
https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.0-insiders
Local variables are now working correctly! 馃帄
I also noted that I didn't need to define __GNUC__ for the IntelliSense to start working. I only had to switch to clang-x64 for my ARM code to be supported!
Yes, you shouldn't need to set the compiler's default defines anymore either. 馃槂
That's great. Auto complete now works for local variables. Are we going to support Go to Definition for local variables?
@deanagan A fully functioning Go to Definition using the IntelliSense engine requires compilation of multiple translation units and is a major task that we plan to do eventually. Getting go to definition to work with IntelliSense only for local variables (or variables defined in the current translation unit) would be a minor task (you can see the definition/declaration is already found when you hover), but I'm not sure if we plan to spend the time to do that yet.
Thanks for all the work done on this area, and I find no issues with using hover for local variables. However, I do want to point out that goto a local variable works really well for legacy code and benefits a lot of those programmers maintaining/refactoring functions/methods that are hundreds/thousands line long (I know it sucks to be a legacy code maintainer).
Maybe that can be tracked in a new issue.
I find that hovering over a local variable shows the definition, but "Go to definition", "Peek Definition", "Go to Declaration", and "Peek Declaration" all show "No definition found for 'variable'". As the hover works, why don't the other ones work? Using:
Version 1.21.1
Commit 79b44aa704ce542d8ca4a3cc44cfca566e7720f1
Date 2018-03-14T14:46:47.128Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
with
C/C++ for Visual Studio Code 0.16.1
@BillDenton Hover uses results from compiling the current translation unit. We could use the same system to give definitions/declarations for the current translation unit (a relatively small task), but it was decided not do that until we're able to give results for definitions that occur in other translation units (a relatively big task). Obviously, for the local variable case, there's no need to reference other translation units, but it was still decided not to implement yet (maybe if more people recommended we do this in the surveys?).
We are tracking the go to definition issue with #255
what's supposed to work atm?
Using C (not C++) with the following c_cpp_properties.json:
{
"configurations": [
{
"name": "WSL",
"intelliSenseMode": "clang-x64",
"includePath": ["${workspaceFolder}", "${workspaceFolder}/include"],
"defines": ["__linux__", "__x86_64__"],
"browse": {
"path": ["${workspaceFolder}", "${workspaceFolder}/include"],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": ""
},
"cStandard": "c99",
"compilerPath": "${localappdata}/usr/bin/gcc -Wall -Werror -std=c99"
}
],
"version": 4
}
on Windows 10, but compiling in WSL with gcc.
Workspace Settings:
{
"C_Cpp.intelliSenseEngine": "Tag Parser",
"C_Cpp.errorSquiggles": "Enabled",
"C_Cpp.intelliSenseEngineFallback": "Enabled",
}
.) is just everything, _sometimes_ not even things defined in the structthese 10.000 issues being closed and circle-referencing each other and somehow this one are really confusing.^^
same with recognition of undefined function calls. imNowhereDefined(); won't get any error squiggles. but i know that that's another issue.
You need to set "C_Cpp.intelliSenseEngine": "Default" (or just delete the setting) to get semantic-aware IntelliSense.
"Tag Parser" is the old IntelliSense engine which doesn't support local variables, doesn't do error squiggles, and doesn't have type information so it suggests everything.
I've read multiple times about this, and must've kept the wrong setting, thank you.
libpng's functions are now suggested but it tells me stuff like png_byte (a data type) is not defined.
I don't know libpng very well. Do you have a sample I can clone or download?
Oh, it works now, seems like the headers weren't crawled or something. Alrighty, I can work with this. Thanks for the fast responses! 馃憤
This is so weird.. the definitions disappeared somehow.. I installed libpng via sudo apt-get install libpng-dev. This is a simple code, enough to trigger what I'm talking about:
#include <png.h>
int main(int argc, char **argv)
{
png_byte a = 13;
return 0;
}
png.h is found and i can go to it via context-menupng_byte is not suggested by intellisensepng_byte throws an error, telling me it's undefinedin addition to my config from before, this is my c_cpp_properties.json now:
{
"configurations": [
{
"name": "WSL",
"intelliSenseMode": "clang-x64",
"includePath": [
"${workspaceFolder}",
"${workspaceFolder}/include",
"${localappdata}/usr/local/include",
"${localappdata}/usr/include/x86_64-linux-gnu",
"${localappdata}/usr/include"
],
"defines": ["__linux__", "__x86_64__"],
"browse": {
"path": [
"${workspaceFolder}/*",
"${localappdata}/usr/local/include/*",
"${localappdata}/usr/include/x86_64-linux-gnu/*",
"${localappdata}/usr/include/*"
],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": ""
},
"cStandard": "c99",
"compilerPath": "${localappdata}/usr/bin/gcc -Wall -Werror -std=c99"
}
],
"version": 4
}
It looks like libpng is not in your include path. You will either need to add #include <libpng/png.h> to your code, or add /usr/include/libpng to your include path.
BTW, your config can be simplified. You shouldn't list the system include paths if you set compilerPath (we accept linux-style paths for WSL), and you don't need browse.path if it's the same as includePath
{
"configurations": [
{
"name": "WSL",
"intelliSenseMode": "clang-x64",
"includePath": [
"${workspaceFolder}",
"${workspaceFolder}/include",
"/usr/include/libpng"
],
"defines": ["__linux__", "__x86_64__"],
"cStandard": "c99",
"compilerPath": "/usr/bin/gcc -Wall -Werror -std=c99"
}
],
"version": 4
}
thanks for the intel, it works as expected now! :)
Keep getting the wrong members after a dereference:

on Ubuntu 16.04. The hints proposed by intellisense are from all the classes I have in the workspace (very large list), instead Touch class members.
C_cpp_properties.json includes the paths of all the workspace (which contains the class Touch):
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [],
"compilerPath": "/usr/bin/clang",
"cStandard": "c11",
"cppStandard": "c++17",
"intelliSenseMode": "clang-x64"
}
],
"version": 4
}
The configuration of intellisense is set as Default
"C_Cpp.intelliSenseEngineFallback": "Disabled",
"C_Cpp.intelliSenseEngine": "Default"
Resseting the intellisense Database, reopening the vsCode, etc. But keeps showing all the stuff I have in the workspace.
@guillemmr It's preferred to file a new bug instead of adding it to a close issue. My best guess is that the IntelliSense process could be crashing. Can you enable logging and see if there are error messages?
Most helpful comment
@rdlaner when we get the extension fast enough to list local and global variables we will turn it on and resolve this issue.