Fix failing 3C test for Windows

[secure-sw-dev-bot]

This issue was copied from checkedc/checkedc-clang#956

---

Our previous PR #930 left some tests failing on windows (correctcomputation#345) . These changes should will hopefully fix those tests. We haven't been able to test these a windows build.

[secure-sw-dev-bot]

Comment from @microsoft-cla[bot]:

All CLA requirements met.

[secure-sw-dev-bot]

Comment from @mattmccutchen-cci:

Making sure to notify @mgrang that this has been submitted.

[secure-sw-dev-bot]

Comment from @mgrang:

I have fired off Windows and Linux validations for this PR. Will approve once those pass.

[secure-sw-dev-bot]

Comment from @mgrang:

Windows X64 build still fails with this.

2020-12-09T23:42:43.7625851Z Build FAILED.
2020-12-09T23:42:47.8176448Z 
2020-12-09T23:42:47.8201514Z        "d:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\test\check-clang.vcxproj" (default target) (1) ->
2020-12-09T23:42:47.8205002Z        "D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\tools\3c\3c.vcxproj" (default target) (15) ->
2020-12-09T23:42:47.8208176Z        "D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\lib\3C\clang3C.vcxproj" (default target) (200) ->
2020-12-09T23:42:47.8210416Z        "D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\lib\3C\obj.clang3C.vcxproj" (default target) (216) ->
2020-12-09T23:42:47.8214389Z        (ClCompile target) -> 
2020-12-09T23:42:47.8217542Z          d:\work\6\s\checkedc-clang\clang\lib\3c\arrayboundsinferenceconsumer.cpp(43): error C2039: 'tolower': is not a member of 'std' [D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\lib\3C\obj.clang3C.vcxproj]
2020-12-09T23:42:47.8222311Z          d:\work\6\s\checkedc-clang\clang\lib\3c\arrayboundsinferenceconsumer.cpp(45): error C2039: 'tolower': is not a member of 'std' [D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\lib\3C\obj.clang3C.vcxproj]
2020-12-09T23:42:47.8226332Z          d:\work\6\s\checkedc-clang\clang\lib\3c\arrayboundsinferenceconsumer.cpp(60): error C2039: 'tolower': is not a member of 'std' [D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\lib\3C\obj.clang3C.vcxproj]
2020-12-09T23:42:47.8230028Z          d:\work\6\s\checkedc-clang\clang\lib\3c\arrayboundsinferenceconsumer.cpp(76): error C2039: 'tolower': is not a member of 'std' [D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\lib\3C\obj.clang3C.vcxproj]
2020-12-09T23:42:47.8232363Z 
2020-12-09T23:42:47.8233233Z     0 Warning(s)
2020-12-09T23:42:47.8234210Z     4 Error(s)

[secure-sw-dev-bot]

Comment from @mattmccutchen-cci:

2020-12-09T23:42:47.8217542Z          d:\work\6\s\checkedc-clang\clang\lib\3c\arrayboundsinferenceconsumer.cpp(43): error C2039: 'tolower': is not a member of 'std' [D:\work\6\b\LLVM-Debug-AMD64-Windows.obj\tools\clang\lib\3C\obj.clang3C.vcxproj]

It's odd if this failure did not manifest when you originally filed correctcomputation/checkedc-clang#345. But based on ea1edad, I'm guessing the culprit is the loss of the #include <cctype>. That may have happened for a similar reason as the loss of /bigobj, which is still on my to-do list to investigate. For now, I'll add the include back.

[secure-sw-dev-bot]

Comment from @mgrang:

Several unit tests seem to be still failing.

         $ ":" "RUN: at line 1"
         $ "3c" "-alltypes" "-addcr" "D:\work\6\s\checkedc-clang\clang\test\3C\graphs2.c" "--"
         # command stderr:
         Assertion failed: "FunctionDecl doesn't have function type?" && !TypeLoc.isNull(), file d:\work\6\s\checkedc-clang\clang\include\clang\3c\rewriteutils.h, line 97

We are currently discussing ways to enable you to validate your changes on Windows. Because this PR seems to be taking more than a couple of iterations I would suggest we keep the tests disabled until you are able to run your validations.

[secure-sw-dev-bot]

Comment from @mwhicks1:

We are currently discussing ways to enable you to validate your changes on Windows. Because this PR seems to be taking more than a couple of iterations I would suggest we keep the tests disabled until you are able to run your validations.

We have some guesses on what the problem what might be, so we could try to push those. But if you can provide us a way to test on Windows, we can do that first. Let us know what you'd prefer.

[secure-sw-dev-bot]

Comment from @john-h-kastner:

@mgrang , the latest batch of commits fixes all the errors we found when testing 3C on a windows VM.

[secure-sw-dev-bot]

Comment from @mgrang:

Thanks for fixing this. I verified that the X64 Windows build passes with your latest commit set. LGTM.

[secure-sw-dev-bot]

Comment from @mgrang:

Could you please also validate the 32bit compiler on Windows? I see that one test is still failing with the 32bit compiler on Windows:

2020-12-29T21:56:10.2775824Z FAIL: Clang :: 3C/definedType.c (134 of 15682)
2020-12-29T21:56:10.3178512Z ******************** TEST 'Clang :: 3C/definedType.c' FAILED ********************
2020-12-29T21:56:10.3190875Z Script:
2020-12-29T21:56:10.3191946Z --
2020-12-29T21:56:10.3194372Z : 'RUN: at line 1';   3c -addcr -alltypes D:\work\14\s\clang\test\3C\definedType.c -- | d:\work\14\b\llvm-debug-x86-windows.obj\bin\filecheck.exe -match-full-lines -check-prefixes="CHECK_ALL","CHECK" D:\work\14\s\clang\test\3C\definedType.c
2020-12-29T21:56:10.3197802Z : 'RUN: at line 2';   3c -addcr D:\work\14\s\clang\test\3C\definedType.c -- | d:\work\14\b\llvm-debug-x86-windows.obj\bin\filecheck.exe -match-full-lines -check-prefixes="CHECK_NOALL","CHECK" D:\work\14\s\clang\test\3C\definedType.c
2020-12-29T21:56:10.3200776Z : 'RUN: at line 3';   3c -addcr D:\work\14\s\clang\test\3C\definedType.c -- | d:\work\14\b\llvm-debug-x86-windows.obj\bin\clang.exe -c -fcheckedc-extension -x c -o /dev/null -
2020-12-29T21:56:10.3202729Z : 'RUN: at line 4';   3c -alltypes -output-postfix=checked D:\work\14\s\clang\test\3C\definedType.c
2020-12-29T21:56:10.3204978Z : 'RUN: at line 5';   3c -alltypes D:\work\14\s\clang\test\3C/definedType.checked.c -- | d:\work\14\b\llvm-debug-x86-windows.obj\bin\count.exe 0
2020-12-29T21:56:10.3206649Z : 'RUN: at line 6';   rm D:\work\14\s\clang\test\3C/definedType.checked.c
2020-12-29T21:56:10.3207546Z --
2020-12-29T21:56:10.3208252Z Exit Code: 1
2020-12-29T21:56:10.3208812Z 
2020-12-29T21:56:10.3209452Z Command Output (stdout):
2020-12-29T21:56:10.3210066Z --
2020-12-29T21:56:10.3210711Z $ ":" "RUN: at line 1"
2020-12-29T21:56:10.3211654Z $ "3c" "-addcr" "-alltypes" "D:\work\14\s\clang\test\3C\definedType.c" "--"
2020-12-29T21:56:10.3213850Z $ "d:\work\14\b\llvm-debug-x86-windows.obj\bin\filecheck.exe" "-match-full-lines" "-check-prefixes=CHECK_ALL,CHECK" "D:\work\14\s\clang\test\3C\definedType.c"
2020-12-29T21:56:10.3216940Z # command stderr:
2020-12-29T21:56:10.3218659Z D:\work\14\s\clang\test\3C\definedType.c:17:15: error: CHECK_ALL: expected string not found in input
2020-12-29T21:56:10.3220133Z 
2020-12-29T21:56:10.3221491Z // CHECK_ALL: _Array_ptr<ulong> TOP = ((void *)0);
2020-12-29T21:56:10.3222716Z 
2020-12-29T21:56:10.3223812Z               ^
2020-12-29T21:56:10.3224739Z 
2020-12-29T21:56:10.3225922Z <stdin>:1:1: note: scanning from here
2020-12-29T21:56:10.3226986Z 
2020-12-29T21:56:10.3228673Z // RUN: 3c -addcr -alltypes %s -- | FileCheck -match-full-lines -check-prefixes="CHECK_ALL","CHECK" %s
2020-12-29T21:56:10.3230237Z 
2020-12-29T21:56:10.3231243Z ^
2020-12-29T21:56:10.3232125Z 
2020-12-29T21:56:10.3233367Z <stdin>:17:13: note: possible intended match here
2020-12-29T21:56:10.3234497Z 
2020-12-29T21:56:10.3235808Z // CHECK_ALL: _Array_ptr<ulong> TOP = ((void *)0);
2020-12-29T21:56:10.3236997Z 
2020-12-29T21:56:10.3237994Z             ^
2020-12-29T21:56:10.3238966Z 
2020-12-29T21:56:10.3239812Z 
2020-12-29T21:56:10.3241048Z error: command failed with exit status: 1

[secure-sw-dev-bot]

Comment from @mgrang:

The reason that I could not validate Windows X86 build before merging this PR is because that build never seems to complete if run manually. This is because the build uses 32 bit MSVC linker for building clang. This should get fixed if we switch it to use the 64 bit MSVC linker. But we would only be able to do that after our source upgrade is complete.

[secure-sw-dev-bot]

Comment from @mattmccutchen-cci:

@mgrang If you could not complete a manual build on Windows x86, I doubt we will be able to either. (John said he tried and ran into a problem; I didn't ask what it was.) Wouldn't it be more reasonable to mark the failing test unsupported on Windows x86 (or if that isn't easy, all Windows) until you fix the linker issue you mentioned, and then we can retry the manual build on Windows x86? As with the previous test failures, I think it will be more efficient if you iterate on getting the right UNSUPPORTED directive (either Windows x86 or all Windows) rather than us.

[secure-sw-dev-bot]

Comment from @mgrang:

@mgrang If you could not complete a manual build on Windows x86, I doubt we will be able to either. (John said he tried and ran into a problem; I didn't ask what it was.) Wouldn't it be more reasonable to mark the failing test unsupported on Windows x86 (or if that isn't easy, all Windows) until you fix the linker issue you mentioned, and then we can retry the manual build on Windows x86? As with the previous test failures, I think it will be more efficient if you iterate on getting the right UNSUPPORTED directive (either Windows x86 or all Windows) rather than us.

AFAIK, there is no way to disable a test only for Windows X86. We need to disable for all Windows. You can refer to this (the current) PR for the correct UNSUPPORTED directive (it is the one that John reverted when he re-enabled the tests).

[secure-sw-dev-bot]

Comment from @mattmccutchen-cci:

AFAIK, there is no way to disable a test only for Windows X86. We need to disable for all Windows. You can refer to this (the current) PR for the correct UNSUPPORTED directive (it is the one that John reverted when he re-enabled the tests).

Sure: #961