Skip to content

Commit eea4ccd

Browse files
committed
Work around clang-cl weirdness for subdoc with an empty class
clang-cl says the data size is 1, no other compiler agrees.
1 parent d4768e2 commit eea4ccd

File tree

1 file changed

+9
-1
lines changed

1 file changed

+9
-1
lines changed

subspace/ops/range_unittest.cc

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,7 @@
1616

1717
#include "googletest/include/gtest/gtest.h"
1818
#include "subspace/construct/default.h"
19+
#include "subspace/macros/compiler.h"
1920
#include "subspace/prelude.h"
2021

2122
namespace {
@@ -68,8 +69,15 @@ static_assert(sus::mem::relocate_by_memcpy<sus::ops::Range<usize>>);
6869
static_assert(sus::mem::relocate_by_memcpy<sus::ops::RangeFrom<usize>>);
6970
static_assert(sus::mem::relocate_by_memcpy<sus::ops::RangeTo<usize>>);
7071
// RangeFull has a 0 data size so it's not (0 is indistinguishable from the
71-
// error case and doesn't need to be memcpy'd).
72+
// error case and doesn't need to be memcpy'd). But on clang, it is marked
73+
// trivial_abi, so it can be seen as trivially relocatable there.
74+
//
75+
// However clang-cl (as seen via subdoc) does something weird here, and makes
76+
// the data size into 1.
77+
#if !(_MSC_VER && defined(__clang__))
78+
static_assert(sus::mem::data_size_of<sus::ops::RangeFull<usize>>() == 0u);
7279
static_assert(!sus::mem::relocate_by_memcpy<sus::ops::RangeFull<usize>>);
80+
#endif
7381

7482
// The types produced by the various literal syntaxes.
7583
static_assert(std::same_as<decltype(".."_r), sus::ops::RangeFull<usize>>);

0 commit comments

Comments
 (0)