Support code completion

[csholmq]

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

[agauniyal]

Is this being worked on? this issue is relevant to #180 though.

[csholmq]

@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?

[csholmq]

@sean-mcmanus @pieandcakes Anything in the roadmap? :)

[sean-mcmanus]

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).

[csholmq]

@sean-mcmanus Nice to hear :) Looking forward to improvements on this already excellent extension!

[KeplerIO]

Code completion and Intellisense don't work what so ever in VSCode.. literally like it isn't even there.

[bootsector]

What plugin do you guys recommend using while this feature is not mature enough in vscode-cpptools?

[KeplerIO]

@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..

[bootsector]

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...

[KeplerIO]

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.

[bobbrow]

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

[csholmq]

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!

[bobbrow]

Yes, you shouldn't need to set the compiler's default defines anymore either. 😃

[deanagan]

That's great. Auto complete now works for local variables. Are we going to support Go to Definition for local variables?

[sean-mcmanus]

@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.

[deanagan]

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).

[tristan957]

Maybe that can be tracked in a new issue.

[BillDenton]

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

[sean-mcmanus]

@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?).

[bobbrow]

We are tracking the go to definition issue with #255

[nitwhiz]

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",
}

• local stuff won't be suggested
• functions from libpng won't be suggested (the general defines are suggested)
• struct stuff (after .) is just everything, sometimes not even things defined in the struct

these 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.

[bobbrow]

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.

[nitwhiz]

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.

[bobbrow]

I don't know libpng very well. Do you have a sample I can clone or download?

[nitwhiz]

Oh, it works now, seems like the headers weren't crawled or something. Alrighty, I can work with this. Thanks for the fast responses! 👍

[nitwhiz]

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;
}

1. png.h is found and i can go to it via context-menu
2. png_byte is not suggested by intellisense
3. png_byte throws an error, telling me it's undefined
4. gcc compiles it without any error (except unused variable in this case)

in 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
}

[bobbrow]

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
}

[nitwhiz]

thanks for the intel, it works as expected now! :)

[guillemmr]

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.

[sean-mcmanus]

@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?