Bug 93506 - Create hybrid of -I and -isystem that is like -I but deactivates warnings
Summary: Create hybrid of -I and -isystem that is like -I but deactivates warnings
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2020-01-30 10:17 UTC by fiesh
Modified: 2021-09-13 00:08 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-01-30 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fiesh 2020-01-30 10:17:53 UTC
Being guilty of abusing -isystem a lot to silence warnings in third-party libraries, it would be great if there were a spin off of -I that ignored warnings just like -isystem does but otherwise behaves like -I.

(An argument that is brought up sometimes, namely that third-party libraries should fix their warnings, isn't really valid I believe.

For example, constexpr variables became implicitly inline in C++17.  Before that, one had to define them in translation units.  So libraries remaining pre-C++17 compatible will want to do that, while projects that compile in C++17 might prefer warnings about deprecated things being done.

Also, from a practicality point of view, it is simply not a meaningful argument.)
Comment 1 Jonathan Wakely 2020-01-30 10:25:11 UTC
For example, see PR 70129 where people are having problems because they're abusing -isystem to get rid of warnings, and that breaks libstdc++ headers.

Rather than yet another -I option (which wouldn't be portable) a better solution might be a separate option that you use in addition to -I to mark that path with the "treat as system headers and don't warn"

i.e. -I /some/path -fsystem-headers=/some/path

This assumes that the "it's a system header path" property is a flag that can be set independently of being in the actual list of system header locations, rather than just implied.
Comment 2 Jonathan Wakely 2020-01-30 10:37:49 UTC
P.S. the name -fsystem-headers was chosen to mirror -Wsystem-headers because those two options would interact. Marking a dir with -fsystem-headers would cause warnings to be suppressed for headers in that path, -Wsystem-headers would re-enable those warnings.

Another advantage of a separate option is that it could appear anywhere on the command line, order wouldn't matter (whereas order of -I options is obviously significant). That would allow makefiles to have something like:

ifeq(CC,gcc)
GCC_SPECIFIC_CPPFLAGS := -fsystem-headers=/dir/one -fsystem-headers=/dir/three
endif

CPPFLAGS := -I /dir/one -I /dir/two -I /dir/three $(GCC_SPECIFIC_CPPFLAGS)

If the feature was available via a new -Isystem flag you'd need to do something like this to preserve order:

I_ := -I
ifeq(CC,gcc)
I_ := -Isystem
endif

CPPFLAGS := $(I_) /dir/one -I /dir/two $(I_) /dir/three