The default syntax file for C doesn't handle compound literals

[marchelzo]

The current default syntax file for C does not support the standard C syntax for compound literals.

See the image attached below.

The curly brace is highlighted as though there were a syntax error, but in fact the code is perfectly legitimate and compiles under any conforming C99 or C11 implementation.

The default syntax file for C ought to handle this correctly.

[chrisbra]

I think, this can be avoided by reseting some configuration variables, it looks like setting :let c_no_bracket_error=1 fixes the issue. Read the help at :h ft-c-syntax for the various options.

[jamessan]

That doesn't fix the issue; it hides it by turning off highlighting of bracket errors. Why disable highlighting of all possible bracket errors that would be highlighted just because one language feature isn't understood?

[pwseo]

@chrisbra why was this issue closed? @jamessan is right

[tmacd9]

I just bumped into this problem too. This issue should be reopened. @chrisbra - this issue should addressed.

[brammool]

A { inside () is highlighted to be able to spot a missing ).

If you can suggest changing the syntax to still highlight a { inside () without highlighting a legal {, let's see it.

[pwseo]

I didn't mean I can provide the solution, I just said that this is a bug that is still unsolved (thus it's weird to leave it "closed"). With compound literals it's legal to have {} inside (), so the ideal solution would provide both that and the unbalanced brackets/parens visual hints.

On the other hand, if you say it won't be possible because of vim's internals, then it's different, and I won't argue. After all, I'm just an end-user.

[brammool]

Please file the bug with the maintainers of the C standard. The syntax they created is impossible to parse in a simple way.

OK, so that won't solve the problem either. But it's true, the C syntax has gotten so complicated you can't really figure out what it means with regular expressions. And also for humans, I have a hard time understanding the example. Splitting into two lines helps for both:
char *oneCharString = (char[]){*c, 0};
strcat(line, oneCharString);

This issue is closed because it can't be fixed. Unless someone proves me wrong.

[ZyX-I]

@brammool Making { inside brackets error was always incorrect: do not forget about macros, it is not uncommon to write something like HASH_ITER(ht, hi, { code }); in cases when creating macros like HASH_FOREACH(ht, hi) { code } is impossible (BTW, Vim could make good use of this or DICT_ITER, iterating over a hash or dictionary is rather common). This should not be marked as error by default:

1. Compilers are much better at catching unclosed parenthesis: most likely where you see this error and it is an error you will get compilation error and not incorrect behaviour.
2. Setups with plugins like autoclose are rather good at preventing the problem - and rather common.
3. Highlighting valid constructs teaches users to ignore error highlighting. It is by no means obvious that behaviour is configurable.

Figure brace error highlighting is not helpful for most users I know.

[EvilPudding]

let c_no_curly_error = 1 I think is the best for me, but it doesn't seem to be working... the curly braces don't highlight as an error any more, but the closing parenthesis is highlighting as wrong...

[EvilPudding]

It seems to not happen in: ({}) but it happens in ({{}})... Which I use because I'm initiating an array of structures in a function call...