Vscode-cpptools: #pragma once

Created on 16 Jul 2017  路  9Comments  路  Source: microsoft/vscode-cpptools

This may seem like small issue but considering it is first impression a modern C++ programmer might face when starting vscode I think it important.

If you create new file, save as main.h and type the line #pragma once followed by enter key, the autocomplete butchers said code inserting unhelpful _flag suffix turning the code to garbage,

Language Service bug fixed (release pending)

Most helpful comment

Hello,
The issue is still there.
Version 1.22.0 (1.22.0) 6b4d53cdab8bcae1eaaa4934d93c077319b573db 2018-04-05T17:18:47.912Z
screen shot 2018-04-06 at 13 11 37

"intelliSenseMode": "clang-x64"
"compilerPath": "/usr/bin/clang",
"cStandard": "c11",
"cppStandard": "c++17"

All 9 comments

Thanks for reporting this. It just missed the cutoff for 0.12.1, but we can get a fix in soon after that.

For the next release, we've disabled it for our results, but VS Code itself has editor.wordBasedSuggestions and editor.quickSuggestions that we can't disable (appears with an "abc" symbol). We've filed bug https://github.com/Microsoft/vscode/issues/31075 on VS Code to enable us to fix this further.

Hey there. I'm using 1.16.1. I'm experiencing another issue with #pragma once. Here's what the editor says when I open a header with such line:

file: 'file:///Users/iv/code/shad-cpp/entrance/entrance.h'
severity: 'Info'
message: '#include errors detected. Please update your includePath. IntelliSense features for this translation unit (/Users/iv/code/shad-cpp/entrance/test.cpp) will be provided by the Tag Parser.'
at: '1,1'
source: ''

includePath of the project is a copypaste of gcc -v -E -x c++ - except of the framework directory.

@ivanychev What version of the C++ extension do you have and what OS are you on? That error is not related to #pragma once. It's just showing the error on the 1st line. Can you file a new bug? The problem you're seeing is that your includePath is not set up correctly. In particular, the test.cpp file has a header that can't be found (opening that file should show more info). What does the Problems pane show when you open the test.cpp file?

Hello,
The issue is still there.
Version 1.22.0 (1.22.0) 6b4d53cdab8bcae1eaaa4934d93c077319b573db 2018-04-05T17:18:47.912Z
screen shot 2018-04-06 at 13 11 37

"intelliSenseMode": "clang-x64"
"compilerPath": "/usr/bin/clang",
"cStandard": "c11",
"cppStandard": "c++17"

This is currently expected. If you fix the #include problems with the source file you grayed out in your screenshot, the squiggle will go away. In a future release we won't try to guess a matching source file to use as the translation unit.

Indeed, with unity builds that basically means you have to complete the include path for all the source files in the project before going on and check errors within a single file (also true for the source, not only the header). Too bad I can't directly use the same include paths as the Visual Studio project.

EDIT: That said, it also avoids false positive when typedef or core classes would be included at the highest level (such as a precompiled header) and therefore always available, but never included directly in a header.

@hsandt I'm not sure what you're talking about. What include paths aren't working that work with Visual Studio? We support forcedIncludes and compile_commands.json. Did you post to the wrong issue?

No, I just meant Intellisense will understand not flag some non-trivial include paths (not described from the project root nor the current file directory) because my VS project has defined various include paths. But VS code doesn't know about them so I have to add them manually in the settings, but because of dependencies and various sources including my header (the extreme case because a source for a unity build), I have to dig up and down all the related files and add all the corresponding include paths. Always writing include paths from the project root would probably ease the work, but sometimes it's much more convenient to just write the end of the path, especially for external libraries with headers very deep in a completely different branch of the directory tree.

Was this page helpful?
0 / 5 - 0 ratings