I applied your patch and built it on our internal build bot that failed and these changes worked, so LGTM as well!

In D63600#1554029, @rnk wrote:

This causes the test to fail on Windows:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/7712

There seems to be something wrong with the blamelist, so it didn't send email. I see this in the log from the previous build on that bot:

Updating llvm to 363241 at ...

But buildbot thinks the previous build was testing r364000, so it didn't send any notifications.

printf seems like the wrong command to use to test backslash handling, since it interprets them as escapes. %S expands to a path containing backslashes, and the test logs seem consistent with that theory. I'll go ahead and revert this.

In D63105#1544519, @nickdesaulniers wrote:

There are lots of tests under clang/test/ that target arm-- as a -triple. How is it that they don't fail in the same way? %clang_cc1 -triple arm-- is somehow different?

Hi Ziang,

Hi, the test cxx2a-consteval.cpp that you added in this commit is failing on the PS4 Windows bot.

In D61187#1486249, @probinson wrote:

FYI, we had to disable clangd entirely after this patch, getting a weird problem with lit that we haven't figured out yet.
In case anybody else has seen something like this, and knows what's going on, please let us know.

  Running all regression tests
  llvm-lit.py: C:/j/w/opensource/opensource_to_sce_merge__2/o/llvm\utils\lit\lit\llvm\config.py:336: fatal: couldn't find 'clang' program, try setting CLANG in your environment
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 2. [C:\j\w\opensource\opensource_to_sce_merge__2\build\check-all.vcxproj]

In D54975#1394068, @dyung wrote:

Build and test passed for me with Visual Studio 2015 and on Linux. Should I submit the fix?

In D54975#1394044, @dyung wrote:

In D54975#1394002, @dyung wrote:

In D54975#1393783, @mikhail.ramalho wrote:

To be clear, this patch breaks compilation with Visual Studio 2015. Running tests requires that the code can be built, so no I didn't run the tests.

Maybe I didn't express myself very clearly: if you change it to ConstraintSMTType, do the tests pass?

If so, I don't see why not pushing the fix. Unfortunately, I don't have Windows to test it.

I can give it a try. But just to be clear, the fix is to change ConstraintSMTTy on line 22 to ConstraintSMTType? Would line 23 require a similar change, or is it fine as it currently is?

I can answer my own question, both seem to need updating. I am building/testing now.

In D54975#1394002, @dyung wrote:

In D54975#1393783, @mikhail.ramalho wrote:

To be clear, this patch breaks compilation with Visual Studio 2015. Running tests requires that the code can be built, so no I didn't run the tests.

Maybe I didn't express myself very clearly: if you change it to ConstraintSMTType, do the tests pass?

If so, I don't see why not pushing the fix. Unfortunately, I don't have Windows to test it.

I can give it a try. But just to be clear, the fix is to change ConstraintSMTTy on line 22 to ConstraintSMTType? Would line 23 require a similar change, or is it fine as it currently is?

In D54975#1393783, @mikhail.ramalho wrote:

To be clear, this patch breaks compilation with Visual Studio 2015. Running tests requires that the code can be built, so no I didn't run the tests.

Maybe I didn't express myself very clearly: if you change it to ConstraintSMTType, do the tests pass?

If so, I don't see why not pushing the fix. Unfortunately, I don't have Windows to test it.