Skip to content

Fix failing 3C test for Windows #956

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Dec 29, 2020
Merged

Conversation

john-h-kastner
Copy link
Contributor

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.

@ghost
Copy link

ghost commented Dec 8, 2020

CLA assistant check
All CLA requirements met.

@mattmccutchen-cci
Copy link
Member

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

@mgrang
Copy link

mgrang commented Dec 9, 2020

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

@mgrang
Copy link

mgrang commented Dec 10, 2020

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)

@mattmccutchen-cci
Copy link
Member

mattmccutchen-cci commented Dec 10, 2020

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#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.

Hope this fixes a Windows build failure reported by Mandeep.
@mgrang
Copy link

mgrang commented Dec 10, 2020

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.

@mwhicks1
Copy link
Contributor

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.

john-h-kastner and others added 7 commits December 28, 2020 16:21
This avoids an assertion fail on some windows header files.
Windows doesn't have sigaction, and we couldn't find a reasonable
alternative.
This is the same workaround used in many other tests for a
Windows-specific problem where 3C thinks it isn't allowed to write a
file because (1) it isn't under the base dir (which defaults to
something under the build directory) and (2) the backslash in the
canonicalized file path doesn't match the hard-coded forward slash in
the RUN command.  We should probably fix this silly problem a better
way, but first we may as well apply the workaround we already have.

While I'm here, replace --output-postfix with -output-postfix for
consistency with the other tests.
`#include "rewrite_header.checked.h"` will work just fine to include a
file in the same directory, and %S caused a problem on Windows when it
expanded to a file path including "\3C" and the \3 was interpreted as a
regular expression backreference.
The GnuWin32 `sed -i` has a bug where it leaves its temporary file
behind, and there's no known solution other than to not use it.
A conditional in Constraints.cpp checked if the first character of a
file path was "/" to determine if the path was absolute, but on windows,
an absolute path will start with "C:\".
@john-h-kastner
Copy link
Contributor Author

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

@mgrang
Copy link

mgrang commented Dec 29, 2020

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

@mgrang mgrang merged commit 5999194 into checkedc:master Dec 29, 2020
@mgrang
Copy link

mgrang commented Dec 29, 2020

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

@mgrang
Copy link

mgrang commented Dec 29, 2020

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.

@mattmccutchen-cci
Copy link
Member

@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.

@mgrang
Copy link

mgrang commented Dec 30, 2020

@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).

mattmccutchen-cci added a commit to correctcomputation/checkedc-clang that referenced this pull request Dec 30, 2020
@mattmccutchen-cci
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants