Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

On 6/8/16, 11:12 AM, "tha...@google.com on behalf of Nico Weber" wrote: >On Wed, Jun 8, 2016 at 1:56 PM, Eric Niebler  wrote: >> >>(adding back cfe-commits, answers inline) >> >>On 6/8/16, 10:11 AM, "tha...@google.com on behalf

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

(adding back cfe-commits, answers inline) On 6/8/16, 10:11 AM, "tha...@google.com on behalf of Nico Weber" wrote: >Sounds like "commit to the current file case and fix all the world's includes" >then :-) (MinGW's windows headers have

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

On Wed, Jun 8, 2016 at 1:56 PM, Eric Niebler wrote: > (adding back cfe-commits, answers inline) > > On 6/8/16, 10:11 AM, "tha...@google.com on behalf of Nico Weber" < > tha...@google.com on behalf of tha...@chromium.org> wrote: > >Sounds like "commit to the current file case and

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

I reverted the patch with r271761 and r271764. Thanks, Taewook On 6/3/16, 6:40 PM, "Bruno Cardoso Lopes" wrote: >> The information about whether the file is in a system path is already being >> computed, so it would incur no extra overhead. I'm not sure that's the

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

> The information about whether the file is in a system path is already being > computed, so it would incur no extra overhead. I'm not sure that's the right > fix. You are more than welcome to revert the (clang) commit while we think > of the right fix. I'm not sure what the right fix is either,

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

The information about whether the file is in a system path is already being computed, so it would incur no extra overhead. I'm not sure that's the right fix. You are more than welcome to revert the (clang) commit while we think of the right fix. \e On Jun 3, 2016 5:25 PM, "Bruno Cardoso Lopes"

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

I think this should be reverted until we figure out how to solve it. Moreover, it looks expensive to check for each file if it's within a system path. I would really like to measure compile time for this change before it goes definitely in. On Fri, Jun 3, 2016 at 4:53 PM, Justin Bogner via

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Taewook Oh via cfe-commits writes: > Author: twoh > Date: Fri Jun 3 13:52:51 2016 > New Revision: 271708 > > URL: http://llvm.org/viewvc/llvm-project?rev=271708=rev > Log: > Use the name of the file on disk to issue a new diagnostic about > non-portable #include and

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

On 6/3/16, 3:24 PM, "tha...@google.com on behalf of Nico Weber" wrote: > On Fri, Jun 3, 2016 at 6:14 PM, Eric Niebler wrote: >> I just checked, and warnings are not emitted from files in an -isystem path. >> I didn’t have to

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

On Fri, Jun 3, 2016 at 7:07 PM, Eric Niebler 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 wrote: > >> I just checked, and

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

On Fri, Jun 3, 2016 at 6:14 PM, Eric Niebler 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 >

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

I can investigate the system header issue. And I could add a special exception for if folks feel that that’s the right thing to do. If we’re really worried about how noisy this warning could be, the warning could be disabled by default. Thoughts? Eric On 6/3/16, 2:46 PM,

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

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

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

It's not just windows.h, but windows sdk headers in general (#include , #include #include #include etc). Here's what the warning does on the first few files in Chromium: https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin/builds/8155/steps/compile/logs/stdio (We add /FIIntrin.h --

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Also, once that is resolved, this warning tells people that #include is wrong: ..\..\third_party\ffmpeg\compat/w32pthreads.h(39,10): warning: non-portable path to file ''; specified path differs in case from file name on disk [-Wnonportable-include-path] #include ^~~

Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

I'm getting lots of warnings like so: In file included from ..\..\tools\win\static_initializers\static_initializers.cc:5: C:\b\depot_tools\win_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97\DIA SDK\include\dia2.h(30,10): error: non-portable path to file '"Windows.h"'; specified path

r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Author: twoh Date: Fri Jun 3 13:52:51 2016 New Revision: 271708 URL: http://llvm.org/viewvc/llvm-project?rev=271708=rev Log: Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths. Differential Revision: http://reviews.llvm.org/D19843