- User Since
- Dec 13 2018, 6:10 PM (93 w, 8 h)
Wed, Sep 2
Wed, Aug 26
Sorry again about the break! As with the initial patch, I'll need you to land this change.
Aug 25 2020
Thanks @hans! I'll need you (or someone else with permission) to land the change on my behalf.
The real reason we don't see it internally is because we use -c for all compilation.
It felt too invasive to swap the precedence of using vctoolsdir vs %INCLUDE% for all clang-cl users so I compromised by skipping the %INCLUDE% check when vctoolsdir was passed on the command line. This way only the users of the new flag will see different behavior.
Aug 24 2020
@hans the explicit path must be declared, all exes and dlls. The unexpected probes for link.exe when invoking clang-cl.exe when it isn't actually going to be invoked are what we want to avoid.
Good call @aganea on these comments. Updated
Updates as requested
Aug 21 2020
We use BuildXL. Thanks for the comments. I'll make the requested changes and get a new rev posted.
The build system strives to be deterministic so all file probes need to be accounted for; environment variables are also problematic. Our builds deliberately don't run from a Visual Studio command prompt. In addition, we'd like to avoid coupling clang tools that don't perform codegen to link.exe. We do use -fmsc-version= during the build.
Aug 15 2020
Once accepted, someone else will need to submit on my behalf.
Aug 14 2020
Jan 14 2020
Wild guess is that 2> %t.err should be removed from the -verify lines? That change passes in the single env I have access to. @rnk any idea what might be going on?
Jan 13 2020
Incorporate review feedback.
Jan 9 2020
My change keeps the diagnostic so consumers can opt into the same enforcement that exists today. Furthermore, the existing fuzzy-pch.c tests show that new -D flags are allowed under a "clangier" PCH structure. None of the existing tests error on:
BAR bar = 17;
when -DBar=int is only part of the the test file's command line.
Jan 8 2020
Dec 18 2019
Fixed MemorySanitizer: use-of-uninitialized-value warning
Sorry about that I'll add a corrected patch
Dec 17 2019
@rnk Can you please submit on my behalf. I don't have commit access.
Dec 12 2019
Dec 10 2019
Thanks Hans! I'll need someone to do the actual submission since I don't have commit rights.
Dec 8 2019
In our build system every file access in an "output directory" needs to be accounted for. Until this patch, the random temporary file name has forced us to rely on workarounds that hurt build throughput.
Dec 5 2019
Updated with review feedback and formatting fixes
Nov 22 2019
Sep 17 2019
I just checked a trivial mismatch example in clang 8.0 (https://godbolt.org/z/wiSAp6) and I missed how the compatibility mode operates. I withdraw my suggestion since the patch keeps consistency with the existing behavior. Thanks for the -Werror=microsoft-exception-spec suggestion that's exactly what our project wants.
Is there any interest in supporting the cl.exe flag /permissive-? I considered a hard error on mismatched exception specifier in clang-cl a feature, not a bug. If msvc compat mode respected that flag this could continue to be an error with that flag set (and upgraded strictness in other cases).
Sep 12 2019
May 31 2019
Jan 24 2019
Jan 8 2019
Dec 17 2018
Same as the corresponding mangling patch, I'd appreciate someone else landing this since I don't have check-in permission.
I don't have check-in permission, so I'd appreciate if someone could handle the actual commit.
Added support for msvc minor version as requested. Tied the updated mangling scheme to C++17 & compatibility mode > 1912 (15.5). Added additional tests.