-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support gnu standard versions for querying compiler #2782
Comments
I repro the issue. It looks like _GNU_SOURCE needs to be defined for c files, not C++. Using gnu11 is supposed to work in terms of the defines that are used, but we could have a bug. You can workaround this bug via adding "_GNU_SOURCE" to the defines section of c_cpp_properties.json (or C_Cpp.default.defines in settings.json). |
But from what I read at https://exceptionshub.com/_gnu_source-and-__use_gnu.html it sounds like maybe users are expected to define _GNU_SOURCE themselves in their build process or code (I haven't verified that though). |
I have this same problem. The underlying cause seem to be that when cpptools is querying the compiler defines, it passes something like The presence of Perhaps you be able to set the |
@travisdowns Ah, thanks for the info. Maybe we can add the gnu std versions when we add C++20 versions. |
@sean-mcmanus - thanks! In the meantime it would be nice to have a bit more visibility into exactly how the cpptools extension is determining the args, e.g., in the debug log it the command line used to invoke gcc doesn't appear, but it would be very useful it it did (since various things are unclear, e.g., if you add to |
@travisdowns The user compilerPath args get added to the front of the args that we add, so any "-std" set by the user is overwritten by the one we set. |
It would be really nice if the generated The only workaround I've found is to pass bogus arguments to the compiler so that it errors out and doesn't report any definitions at all. Then, I can set the ones I need manually. |
Closes microsoft#2782 - Add the ability for the user to pick gnu standards for the cppStandard and cStandard options. - While I was in there I added the c17 cStandard that was missing.
When the gnu options are supported will they auto configure from the compile_commands.json? ie my project emits a compile_commands.json that includes -std=gnu11, will all the red squiggles go away once this is fixed? We expect the project to compile in glibc's -D_DEFAULT_SOURCE mode as is the default for all the -std=gnu* options. Not in STRICT_ANSI mode as vs code defaults to. It is a significant, practicle differnce that was very hard to uncover as being caused by -std. |
@jgunthorpe If your project uses one "std" then I believe it would work to just set that in the c_cpp_properties.json; however, if you require the "std" to be picked up in the compile_commands.json command arguments, then we would also need to fix #1755 (the workaround for that for non-std flags is to pass the arguments in the compilerPath or compilerArgs properties). |
The gnu standards are supported now with https://github.com/microsoft/vscode-cpptools/releases/tag/0.28.0-insiders2 . Let us know if you hit any issues with that. |
Thanks! Can you give a one-liner one how to use it? Is it like |
The GNU standards were added as additional options to properties |
...or "-std=gnu++17" if it's part of compilerArgs, args in compile_commands.json, etc. |
This issue is fixed in 0.28.0. |
Hi, I am receiving the error
identifier "CLOCK_MONOTONIC" is undefined
from cpptools for the below code, which I don't receive when compiling with gcc. If I include"defines": ["_POSIX_C_SOURCE 199309L"]
inc_cpp_properties.json
then the issue is resolved and cpptools doesn't complain.My question is, why is this behavior different when I compile with gcc? I believe the default C standard for gcc is gnu11, which doesn't require
_POSIX_C_SOURCE
to be defined. Is cpptools using a different standard, and if so is there a way to force using gnu11? I've tried adding-std=gnu11
to the compiler path, but that doesn't seem to solve the issue.The text was updated successfully, but these errors were encountered: