Vscode-cpptools: Intellisense not recognizing initializer lists

Created on 6 Jan 2019  路  10Comments  路  Source: microsoft/vscode-cpptools

Hello, I'm wondering why any initializer list like int x{100}; are not recognized. Sometimes the syntax error disappears after a compile is finished but reappear once the file is edited and saved. The semicolon is always expected instead of a curly brace.

I'm using the clang-x64 intellisense mode with the latest version of C/C++ extension in the latest VS Code Insiders on a Mac.

Language Service more info needed

Most helpful comment

@sean-mcmanus Got the culprit. It's caused by the C/C++ Clang Command Adapter extension. Once it's disabled the problem is gone. I have no idea how this extension got in the way to cause this problem. Thank you very much to catch the message!

All 10 comments

Try setting cppStandard to c++11 or higher?

This is normally supposed to work. It's also possible your file is getting incorrectly interpreted as C instead of C++ incorrectly. e.g. ".C" files are normally C++ files, but VS Code isn't able to correctly recognize the casing...you could still add "*.C": "cpp" to your files.associations setting to fix this, but that will also treat ".c" files as C++ instead of C.

@HigHwindEx I noticed in your deleted comment you mentioned __int128_t -- I assume you found we added that to our Insiders build.

@HigHwindEx @sean-mcmanus The cpp standard was set to c++17 in the c_cpp_properties.json and I also added -std=c++11 in the clang command line. The file extension in question is indeed .cpp. Do you need anything else?

Why did you use -std=c++11 instead of -std=c++17 on the command line, I assume in the compilerPath? We should already pass that so it shouldn't be necessary to re-add.

I would enable Debug logging and look for anything unexpected when you open a file, i.e. you should see "stdver: c++17".

The problem is gone if I use the standard build of VS Code with -std=c++0x in the apple Clang compiler commands. The Insiders is so stubborn that it refuses that syntax no matter what. The error is always the same: expected ';' at end of declaration.

I don't understand your comment. By "standard build of VS Code" do you mean 0.20.1 of the C/C++ extension? Are you saying there is a regression with 0.21.0-insiders3? We didn't make any change related to how -std input is processed with compilerPath. I don't understand what you mean by "apple Clang compiler commands" -- are you referring to a compilerPath setting or a compile_commands.json you're using? We expect users to not use "-std=c++0x" and instead set the C_Cpp.default.cppStandard setting to c++11. I'm not seeing any IntelliSense issue with "int x{100}" with clang and c++11 on Linux.

Sorry for not being very accurate.

By "standard build" I actually meant the stable build of VS Code. The C/C++ extension had always been up-to-date in both versions (stable and insiders). The -std=c++0x was added to the command property of a build task in tasks.json in the Insiders build.

I did what you recommended to remove the -std=c++0x and set C_Cpp.default.cppStandard to c++11 in the insiders build but to no avail. The stable build of VS Code does not exhibit this syntax error without any specific configuration. It just works.

Again, these all happen on a Mac. The Clang compiler version is Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin18.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin.

@elliottye I noticed the "expected a ; at end of declaratin" message you mentioned previously is not output by our extension -- can you disable the other extension you have installed that is causing that message?

Otherwise, I need to know what the version number of our C/C++ extension you're using. Can you set the updateChannel to "Insiders" to get the 0.21.0-insiders3? Also, can you enable Debug logging and see what output occurs when you open a new C++ file with the "int x{100}"? You want to see "--c++11" at the end of the logs. I'm not reproing the problem on Mac with clang 10.

@sean-mcmanus Got the culprit. It's caused by the C/C++ Clang Command Adapter extension. Once it's disabled the problem is gone. I have no idea how this extension got in the way to cause this problem. Thank you very much to catch the message!

Was this page helpful?
0 / 5 - 0 ratings