Can we support GCC C extensions?

[VALLIS-NERIA]

For example, typeof keyword, variable length and zero length arrays. Currently many of them are treated as unknown identifiers and the IntelliSense raises many errors.

http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/C-Extensions.html

[sean-mcmanus]

Our parser supports some of the extensions, although we may need to do additional work to get the features turned on, but some of the extensions our parser doesn't support.

[VALLIS-NERIA]

Yes. Some extensions are rarely used but some occurs everywhere in the linux kernel but still not supported. e.g. __attribute__, typeof, and GNU style variable parameter of macros.

static inline __attribute__((format(printf, 1, 2))) __attribute__((__cold__)) int printk(const char *s, ...)

#define max(x, y) ({				        \
	typeof(x) _max1 = (x);			\
	typeof(y) _max2 = (y);			\
	(void) (&_max1 == &_max2);		\
	_max1 > _max2 ? _max1 : _max2; })

#define kthread_create(threadfn, data, namefmt, arg...) \
	kthread_create_on_node(threadfn, data, -1, namefmt, ##arg)

Getting errors like "expected an expression" or "expected a ';' " really destroys the experience.

[sean-mcmanus]

Your first line, the declaration, is missing a ";", so the "expected a ;" appears correct.

After correcting that, the code you use should work without any errors. If there are errors, you may need to set your compilerPath correctly or provide more repro details.

I'm pretty sure there are some GNU extensions we don't support though (from previous users reporting problems with them).

[sean-mcmanus]

Related to https://developercommunity.visualstudio.com/content/problem/194258/cpppropertiesjson-support-stdgnu17-when-using-gcc.html .

[ranolfi]

I'm having a problem where one specific macro defined in the linux kernel code is triggering an intellisense error:

expected a '('

The macro is WARN_ON_ONCE and everywhere it is used the error is the same. In one instance (in the file I'm working on), I ran the C preprocessor to figure out exactly what is triggering the error, and it seems to be the __inline statement:

(this code is taken from https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/x86/kernel/cpu/rdrand.c.)

I'm using the setup from https://github.com/amezin/vscode-linux-kernel to browse the kernel tree with VS Code.

@sean-mcmanus, is this also a matter of C standard? The top-level compile_commands.json file defines -std=gnu89 as an argument to the compile command for this file, but I noticed the extension does not take that into account.

Just making sure I'm having a similar enough problem to OP so as to not open a new issue.

[sean-mcmanus]

@ranolfi

We tracking support for the gnu versions at #2782 .

The error is caused by usage of "asm __inline" which is a gcc extension that our parser does not support.

[RaspStudio]

Can we support "Statement Exprs"? @sean-mcmanus
I got "expected an expression" when using macros like:

#define PADDR(kva)                                                                                 \
	({                                                                                         \
		u_long a = (u_long)(kva);                                                          \
		if (a < ULIM)                                                                      \
			panic("... %08lx", a);                           \
		a - ULIM;                                                                          \
	})

I have already set "compilerPath" and "cStandard", but the error still exists. It seems same as earlier posts. I wonder if we can support this feature? https://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Statement-Exprs.html#Statement-Exprs

[sean-mcmanus]

@RaspStudio I don't repro the issue -- can you run the C/C++: Log Diagnostics command and either provide the output or specifically what IntelliSense mode is being used. I don't repro the bug with a gcc IntelliSense mode (only msvc). A complete/compiling code example may also help (I had to add code, which might be different from the code you have).

[RaspStudio]

It seems that I've solved this, and I can't repro this either.
It's quite weird. Yesterday, I added compilerArg "--std=gnu99" in c_cpp_properties.json, and solve this problem(At first I only set "cStandard": "gnu99"), at that time I wondered if "cStandard" doesn't work. But today I tried to repro this situation, but the error doesn't appear when I delete the compilerArgs.

Current Configration.

"cStandard": "gnu99",
"compilerArgs": [
    "--std=gnu99"// Yesterday after adding this it worked correctly
],

I'm so confused but it seems everything is right now. But anyway thank you! @sean-mcmanus