-
Notifications
You must be signed in to change notification settings - Fork 745
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
More checks for non-compilable code, plus fix for span #1180
More checks for non-compilable code, plus fix for span #1180
Conversation
I was not able to replace all checks in the touched files. Functions where the type constraints are not checked with Classes where a type constraint is not checked with The |
2c70176
to
e329a72
Compare
d0cd8ee
to
57e5a91
Compare
b2e7ddc
to
e65ece0
Compare
If desired, I can also move the |
141cd59
to
466e3f7
Compare
711572c
to
a1d2c73
Compare
Done. |
c855f7e
to
02c02cc
Compare
} | ||
static_assert(TypeDeductionCtorCompilesFor<void*>, "TypeDeductionCtorCompilesFor<void*>"); | ||
#if defined(_MSC_VER) | ||
// Fails on gcc, clang, xcode, VS clang with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pipeline stops at the first error. I did not check if this compiles for any of the gcc/clang/xcode versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine. At first glance this looks like an "accepts invalid" for MSVC. We shouldn't be able to create a gsl::not_null<nullptr_t>
. I will investigate further then raise the issue internally.
@@ -216,6 +222,12 @@ TEST(span_test, from_pointer_length_constructor) | |||
|
|||
TEST(span_test, from_pointer_pointer_construction) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function has three commented out checks with comments "// this will fail the std::distance() precondition, which asserts on MSVC debug builds". I tried to activate the tests on different platforms, but then the tests failed. I could not match the comment with the death behaviour of the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not match the comment with the death behaviour of the code.
How does it fail today? I don't see a std::distance
call in gsl/span
, so I wonder if the comment is just out of date.
Probably also worth noting that the &arr[1]
expression is UB so if compilers treat it differently, it may not be a compiler bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that two of the three EXPECT_DEATH
failed because no death occured. The pipeline said line 296 and line 273 failed.
Because of ammending commits I cannot match failed pipelines to still existing commits. But I think these were the test 2 and 3, not the first one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests 2 and 3 are identical? Let me know if I'm missing something. Test 1 is definitely UB.
I think we should delete test 1 and uncomment either test 2 or test 3 (and delete the other).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For std::span
all three tests are UB.
This is the implementation of the gsl::span
ctor.
template <std::size_t MyExtent = Extent, std::enable_if_t<MyExtent != dynamic_extent, int> = 0>
constexpr explicit span(pointer firstElem, pointer lastElem) noexcept
: storage_(firstElem, narrow_cast<std::size_t>(lastElem - firstElem))
{
Expects(lastElem - firstElem == static_cast<difference_type>(Extent));
}
I think for GSL the relevant point is lastElem - firstElem
. For the first case (&arr[0] - &arr[1]) this is OK. The length store in storage_
is not fine, but the Expects
triggers.
For the checks with a nullptr the pointer subtraction should be a problem (the pointers do not point into the same object -> UB).
If I don't miss anything then test one is a test that we can activate, but tests two and three should be deleted or left commented out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think all tests should be deleted. It will be confusing to have tests that may start to fail with a compiler update.
If you see value in keeping them commented out for reference, that's fine. But the false comments about std::distance
should be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests 2 and 3 are identical? Let me know if I'm missing something. Test 1 is definitely UB.
Your godbolt test is range nullptr[1]..nullptr[0]. Test 1 is arr[1]..arr[0] where arr is a C style array.
I delete the tests 2 and 3. For test 1 you can decide. I think we do not need to assure this behaviour, but if we want to, it does not hurt.
7b8563d
to
4279da5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing macro'd out code for static_assert
s is a great change, thanks!
Just a couple comments/questions/suggestions. Once those are resolved, it will be ready to merge.
} | ||
static_assert(TypeDeductionCtorCompilesFor<void*>, "TypeDeductionCtorCompilesFor<void*>"); | ||
#if defined(_MSC_VER) | ||
// Fails on gcc, clang, xcode, VS clang with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine. At first glance this looks like an "accepts invalid" for MSVC. We shouldn't be able to create a gsl::not_null<nullptr_t>
. I will investigate further then raise the issue internally.
@@ -216,6 +222,12 @@ TEST(span_test, from_pointer_length_constructor) | |||
|
|||
TEST(span_test, from_pointer_pointer_construction) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not match the comment with the death behaviour of the code.
How does it fail today? I don't see a std::distance
call in gsl/span
, so I wonder if the comment is just out of date.
Probably also worth noting that the &arr[1]
expression is UB so if compilers treat it differently, it may not be a compiler bug.
I opened #1181 to address the failing checks.
Edit: merged |
- Remove some of the checks in `#ifdef CONFIRM_COMPILATION_ERRORS` and add compile time checks for these tests. - `algorithm_tests.cpp` and `span_test.cpp` have not been touched.
plus more unit tests for these functions
97b7c00
to
e31f8d7
Compare
Looks good! Thanks for the PR and thanks for making all the requested changes :) |
Expects
failed during runtime#ifdef CONFIRM_COMPILATION_ERRORS
and add compile time checks for these tests.