Some of the existing utils in utils/UnitTest/Test.h have been moved to this new library.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| libc/utils/CPP/Array.h | ||
|---|---|---|
| 24–30 | I know you aren't looking for comments, but just a quick one. std::array has no private members or constructors which makes it an aggregate, which gives it the super nice constexpr brace initializer syntax. This constructor would anyway need a reference to a preexisting array and couldn't be initialized like Array<...> a({1, 2, 3, 4}); If you make Data public (and remove Length because we can just use N) and remove these 2 constructors then it can be initialized like Array<int, 5> arr {1, 2, 3, 4, 5}; | |
Thx @sivachandra
| libc/cmake/modules/LLVMLibCRules.cmake | ||
|---|---|---|
| 379 | Thx! | |
| libc/utils/CPP/Array.h | ||
| 18 | You can use N everywhere, you don't need Length | |
| 24–30 | +1 | |
| libc/utils/CPP/ArrayRef.h | ||
| 61 | That would be nice to have size_t available separately. | |
| 81 | [nit] It might be easier to start from MutableArrayRef as a base type and inherit from it to constrain constness? | |
| libc/utils/UnitTest/Test.h | ||
| 66 | Can we have an explicit specialization that handles comparing two bool? | |
| libc/utils/UnitTest/Test.h | ||
|---|---|---|
| 20–21 | Now that I see it again, I think this should say "return bool" or "return _Bool" | |
| 66 | https://reviews.llvm.org/D73472#inline-667032 and line 20 of this file. | |
| libc/utils/CPP/ArrayRef.h | ||
|---|---|---|
| 81 | Thinking about ArrayRef and MutableArrayRef twists my mind. But, I am only imitating the LLVM arrangement for consistency. Consistency is probably good to avoid surprising ourselves when switching between different pieces of code. | |
| libc/utils/UnitTest/Test.h | ||
| 20–21 | Fixed this and other typos I found. | |
| 66 | I do not want an integral type to be implicitly converted to bool. So, what do you think about supporting [ASSERT|EXPECT]_[TRUE|FALSE] via functions like this: // For [ASSERT|EXPECT]_TRUE.
template <
typename ValType,
cpp::EnableIfType<cpp::IsBoolType<ValType>::Value, ValType> = true>
static bool testTrue(RunContext &Ctx, ValType Val, const char *ValStr,
const char *File, unsigned long Line) {
return Val;
}
// For [ASSERT|EXPECT]_FALSE.
template <
typename ValType,
cpp::EnableIfType<cpp::IsBoolType<ValType>::Value, ValType> = true>
static bool testFalse(RunContext &Ctx, ValType Val, const char *ValStr,
const char *File, unsigned long Line) {
return !Val;
}Use of cpp::IsBoolType ensures that these functions are restricted to boolean values only. | |
Comment about empty arrays
| libc/utils/CPP/Array.h | ||
|---|---|---|
| 37 | This is not needed, as the expression T Data[0] is ill formed see C11 standard Consequently, this should rather be replaced by a static_assert that N != 0 | |
| libc/utils/CPP/ArrayRef.h | ||
|---|---|---|
| 66 | All constructors defere to those of the base class so you should be able to use inheriting constructors aka: | |
| libc/utils/CPP/Array.h | ||
|---|---|---|
| 15–16 | We could make this a struct? | |
| libc/utils/CPP/ArrayRef.h | ||
| 38 | Do we want this to be explicit? I think ArrayRef<T> arr = someT; is a little surprising. | |
| 75–79 | These are constructed from pointers to const T so arguably these constructors should not be allowed. | |
| 87 | Unnecessary this-> | |
| libc/utils/CPP/ArrayRef.h | ||
|---|---|---|
| 66 | It was my mistake that I made them the same. They are not the same as the args are not const qualified in case of MutableArrayRef. See @abrachet's comment below. | |
| 87 | Strange, but this stackoverflow entry is the most accessible explanation I could find: https://stackoverflow.com/questions/19128796/why-can-i-call-base-template-class-method-from-derived-class | |
Thx!