[vim/vim] C++ syntax highlighting does the wrong thing with brace initialization in lambda captures (Issue #11639)
Aaron Jacobs
Steps to reproduce
Input the following code:
auto Foo() { return int64_t{0}; } auto Bar() { return [calls = int64_t{0}]() mutable { return ++calls; }; }
The result is syntax highlighting that shows the second int64_t{0} expression as problematic, and the first as fine:
Expected behaviour
The int64_t{0} expression is valid in both places, so both should be rendered the same (without the pink highlighting in my screenshot).
Version of Vim
9.0
Environment
OS: Linux
$TERM: screen-256color
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
You need to add let g:c_no_curly_error = 1 in your vimrc to suppress this type of syntax error. Don't forget to reload the buffer after that.
There are plenty of other variables that you can set. See :h ft-c-syntax.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Aaron Jacobs
Nice, thanks! Do you know why that isn't the default? It seems like the wrong default as of C++14.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
Note that the defaults are defined in the c syntax file. The file is just also loaded for cpp files since the syntax is very similar. I don't know who wrote the syntax file nor who made those decisions.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Aaron Jacobs
Ack, thanks. Feel free to read this issue as "the defaults are wrong for C++" then, which I think is a legitimate issue. (Great that there's a workaround though, thanks for that.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
C++ is just hard to parse correctly. I guess we have to live with it. Here is a quote from Bram about this
C++ is close to impossible to parse correctly, anything that wasn't an error in the previous version is made to do something meaningful in the next version, it seems. This will continue until any random sequence of characters is meaningful C++ code :-).
I used to know C++ but don't quite understand your example. Is {1,1} a tuple literal?The syntax file was made to highlight the most obvious errors.
You an disable highlighting curly errors, but then Vim won't highlight unpatched "}". It's up to the user to decide what is preferred.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Having said that, this is most likely a duplicate of various of the following issues:
#3551 and possibly others: https://github.com/vim/vim/issues?q=is%3Aissue+c_no_curly_error
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
Since it's a duplicate I think it can be closed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
closing then
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #11639 as not planned.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.