When converted with 3c -alltypes -addcr, the test7 function in clang/test/3C/functionDeclEnd.c gets marked _Checked even though it returns a pointer that doesn't satisfy the declared bounds on the return type:
|
int *test7(int *a) : count(10) { |
|
//CHECK_ALL: _Array_ptr<int> test7(_Array_ptr<int> a) : count(10) _Checked { |
|
//CHECK_NOALL: int *test7(int *a : itype(_Ptr<int>)) : count(10) { |
|
return a; |
|
} |
Starting with
checkedc#1150, this generates a compile error (as it should) and causes the test to fail. So we need to decide what to do about the test. Unless/until we decide, the plan in
checkedc#1150 is to XFAIL the whole test.
I believe the fact that 3C converts the function with incorrect bounds (and 3c -addcr marks it _Checked anyway) falls into the category of "known bounds inference limitations", so the question here becomes how to tweak this test so it still covers the 3C functionality it was originally intended to cover without triggering this unrelated failure. Of course, one option (but probably not the best) would be to simply add an expected-error. @john-h-kastner You originally added the test in #394; do you have an opinion?
When converted with
3c -alltypes -addcr, thetest7function inclang/test/3C/functionDeclEnd.cgets marked_Checkedeven though it returns a pointer that doesn't satisfy the declared bounds on the return type:checkedc-clang/clang/test/3C/functionDeclEnd.c
Lines 141 to 145 in 0fd38a3
Starting with checkedc#1150, this generates a compile error (as it should) and causes the test to fail. So we need to decide what to do about the test. Unless/until we decide, the plan in checkedc#1150 is to XFAIL the whole test.
I believe the fact that 3C converts the function with incorrect bounds (and
3c -addcrmarks it_Checkedanyway) falls into the category of "known bounds inference limitations", so the question here becomes how to tweak this test so it still covers the 3C functionality it was originally intended to cover without triggering this unrelated failure. Of course, one option (but probably not the best) would be to simply add anexpected-error. @john-h-kastner You originally added the test in #394; do you have an opinion?