On 6/3/16, 4:13 PM, "tha...@google.com on behalf of Nico Weber" <tha...@google.com on behalf of tha...@chromium.org> wrote: >On Fri, Jun 3, 2016 at 7:07 PM, Eric Niebler <enieb...@fb.com> wrote: >>On 6/3/16, 3:24 PM, "tha...@google.com on behalf of Nico Weber" >><tha...@google.com on behalf of tha...@chromium.org> wrote: >>> On Fri, Jun 3, 2016 at 6:14 PM, Eric Niebler <enieb...@fb.com> wrote: >>>> I just checked, and warnings are not emitted from files in an -isystem >>>> path. I didn’t have to do anything special to get that behavior. >>>> I don’t know about -imsvc. Is that a clang-cl thing? I can’t say at this >>>> point why the diagnostics system treats -isystem and –imsvc >>>> differently. >>>> >>>> How about this: I can change the diagnostic to not warn about filenames if >>>> the file is found in a system include path, regardless of >>>> the location of the #include directive. >>> >>> That sounds like a good idea to me! >> >> On second thought, this warning isn’t living up to its potential if it >> doesn’t warn on `#include <IoStReAm>`. And if we don’t help people >> find misspellings of IOKIt, we haven’t done much good at all. >> >> Once I sort out the -imsvc thing, how bad would it be to leave it alone? >> Probably pretty bad for folks in the Windows world, huh? > > Yes, the warning is completely unusable there atm.
Here’s my current thinking on the issue: 1) By default, warn only for user includes and the known standard headers (C/C++/posix). 2) Add an additional switch that controls warning for nonportable paths to system includes (disabled by default). Thoughts? \e _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
