Intellisense: Add ignore list for files or individual errors.

In my project there are auto generated headers that is generated in compile time and deleted after. Intellisense do not find header and shows error. Also there are some files that is list of enum values that is inserted in other enum and Intellisense shows error.

Suggestion:
Add ignor list to ignore file, errors in file, or something like that.

If we ignore the file, you will still end up with squiggles in your code because the symbols provided by that header won't be defined, right? I don't think this is something we will get to in the near term.

Yeah, it sounds like you want to change your build system to not delete the generated headers that are used to compile. You can set "C_Cpp.errorSquiggles" to false, but it's not per-file.

+1 It's annoying to have a cluttered Problems pane and significantly inflated count of errors shown in the status bar, which makes it harder for me to tell at a glance how many errors I've actually introduced when developing code changes.

My use case involves a particular generated include file:
You'll notice here that this ordinary header file has an enum definition in which it includes another file named "Attributes.inc", which is automatically generated during the build process for this project. I've added the directory containing the resulting generated file to my includePath, so after building everything, Intellisense successfully finds the generated include file. Interestingly, the header does seem to be parsed successfully by Intellisense, in so far as I do get autocomplete suggestions for values of the Attribute enum when working on code elsewhere, and I get squiggles if I mistype an enum value defined in the generated include file. However, if I try to peek or jump to the definition of an enum value, vscode opens the generated include file (which is great!) and then generates many spurious errors like "this declaration has no storage class or type specifier". This is probably because the generated include file is meant to be included inside of a enum definition, so it cannot be parsed as valid ordinary C/C++ header on its own. I'd really appreciate some way to tell Intellisense to suppress/hide the many warnings from this one file so they do not clutter the Problems pane and avoid contributing to the count of errors in the status bar, but I don't want to remove the generated header from my includePath, as Intellisense is doing a good job using it for autocomplete suggestions and informative squiggle/errors in other files using Attribute enums.

EDIT: For now a workaround is just closing VSCode entirely and relaunching it (w/o opening the problematic include file) which clears away the unwanted errors. This suggests an alternative feature that could help here: it would be nice if it were possible to clear away errors reported for a file that was previously opened and closed that I no longer care about, without having to restart VSCode.

Bob Brown (@bobbrow)

Bob Brown (@bobbrow) wrote:

If we ignore the file, you will still end up with squiggles in your code because the symbols provided by that header won't be defined, right?

In my use case described in the previous comment, I've got an automatically generated include file that Intellisense seems to successfully parse when included by another file (which is really great!), but the problem is if I open the generated include file on its own I get a lot of spurious warnings which I'd like to suppress. It's not "include errors" that I want to suppress, but other errors within a generated file. Sorry if my ignore-some-errors feature request is in the wrong place, I wasn't sure whether to comment in #2345 or here.

This feature request has received enough votes to be added to our backlog.

This could be partially addressed by #2814 , which would add the ability to suppress individual warnings/errors.

My use case is that I use a compiler that has a number of extensions. I can hide most of the extensions from VS Code with preprocessor defines but one of the extensions permits some functions to skip parameters and so I'd like to completely suppress checking for "too few arguments in function call" and "expected an expression".

Things I've ruled out:

Surrounding each of these special function calls with "#ifndef __INTELLISENSE__ " clutters the code too much and often isn't possible (i.e., I'm reading code).

Another approach I've ruled out is adding "VSCODE_SUPPRESS_PARAM_ERR=0" to the "defines" array in c_cpp_properties.json, not defining it in the Makefile, and then writing calls like:

func (p1, VSCODE_SUPPRESS_PARAM_ERR, VSCODE_SUPPRESS_PARAM_ERR, p4);

Again, this clutters the code and makes no sense to my colleagues who don't use VS Code.

I don't see that #2814 applies to #1231. As I understand the former, it request a way to promote warnings to errors.

Ben Voris (@Ben-Voris)

Ben Voris (@Ben-Voris) You may be able to use a forcedInclude file in your local enlistment with

#ifdef __INTELLISENSE__
    #pragma diag_suppress <error code>
#endif

Sean McManus (@sean-mcmanus)

Sean McManus (@sean-mcmanus), your suggestion worked a treat. Thank you.

For those who, like me, don't immediately know how to implement his suggestion, here's what I did.

In c_cpp_properties.json, in the relevant configurations entry, I added this:

            // This file isn't included in the real build (done by Cygwin make), but it
            // affects how VSCode-cpptools parses the source.
            "forcedInclude": ["${workspaceFolder}/.vscode/supress-warnings.h"],

supress-warnings.h contains:

#ifdef __INTELLISENSE__
// 165 - too few arguments in function call
#pragma diag_suppress 165
// 29  - expecting an expression
#pragma diag_suppress 29
#endif

Even if this file were accidentally included, it would do nothing since the compiler I use does not define __INTELLISENSE__.

I don't know what I'll do for projects that have some files that uses the extensions that cause error 165 and 29 and others that do not, but at worst, I can now suppress the errors everywhere and discover the mistake when I build.

Ben Voris (@Ben-Voris)

Ben Voris (@Ben-Voris) this is excellent, minimally-invasive solution. Thank you!

This indeed is a nice solution except it won't work if you're trying to use forcedInclude with compileCommands option as in #8274.

I'd like to note that when you use

#ifdef __INTELLISENSE__
    #pragma diag_suppress 165
#endif

This warning is now suppressed everywhere hereafter in your include tree. You'll probably want to be very explicit about where you disable warnings. I recommend something more like:

#ifdef __INTELLISENSE__
    #pragma diag_suppress 165
#endif
// line that bares the warning here
#ifdef __INTELLISENSE__
    #pragma diag_default 165
#endif

This will ensure that you're warned anywhere else thereafter that may bare the same warning.

Generally it is a good idea to suppress warnings over as little code as possible. But, my requirement was that that source not be modified. Also, it presumes that the warning is real, which is my case it never is.

Any update on this? I'm not trying to disparage the efforts of the VS Code team, but I am curious as to why per-file squiggle configuration has been so difficult to solve. I don't even know where to start looking for the code that does this or how to begin with a PR, but I'm interested in taking a look if someone can point me in the right direction.

@mcmuffin6o No update. VS 2022 doesn't have the ability to filter out per-file squiggles and this feature request hasn't gotten on our schedule so far. I don't think it's a difficult issue. It's possible a filter check could be added at https://github.com/microsoft/vscode-cpptools/blob/main/Extension/src/LanguageServer/client.ts#L147 .

Anything?

Interesting VS-code doesn't have this feature implemented, and considering how much time this issue has been opened for, no reason to think it's going to be added any time soon.

cant actually have this file pre-defined. The only way to make VSCode…

Just checking in. I have a project which includes "config.h" deep inside its own includes. IncludePath finds the source .h files, but the generated config.h (autoconf generated) does not exist. I would like to just tell IntelliSense/VSCode to pretend it exists, or specifically not complain that it doesn't. There should be a way to configure this, as this issue brought up years ago. Build-time auto-created headers is a very normal thing, is there no solution for this use case yet?

ts-ignore

Just checking in. I have a project which includes "config.h" deep inside its own includes. IncludePath finds the source .h files, but the generated config.h (autoconf generated) does not exist. I would like to just tell IntelliSense/VSCode to pretend it exists, or specifically not complain that it doesn't. There should be a way to configure this, as this issue brought up years ago. Build-time auto-created headers is a very normal thing, is there no solution for this use case yet?

I'm having the exact same issue. Super annoying, with typescript eslint you can just //ts-ignore.
I'd like to be able to // NOLINT a specific line and have the errors ignored.

Navigation Menu

Repository navigation

Intellisense: Add ignore list for files or individual errors. #1231

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Intellisense: Add ignore list for files or individual errors. #1231

Description

Activity

bobbrow commented on Nov 10, 2017

sean-mcmanus commented on Nov 10, 2017

VictorYing commented on Sep 1, 2019

VictorYing commented on Sep 5, 2019

github-actions commented on Oct 19, 2020

Colengms commented on Apr 13, 2021

Ben-Voris commented on May 7, 2021

sean-mcmanus commented on May 8, 2021

Ben-Voris commented on May 11, 2021

Bklyn commented on Jun 3, 2021

crackcomm commented on Oct 13, 2021

stoutgz commented on Sep 2, 2022

Ben-Voris commented on Sep 2, 2022

matthewelmer commented on Jul 20, 2023

sean-mcmanus commented on Jul 20, 2023

Rodriggrr commented on Sep 8, 2023

taschenger commented on Nov 24, 2023

cross commented on Aug 10, 2024

ilaffey2 commented on Jan 14, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions