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
- Build Status
Buildable 45091 Build 46747: arc lint + arc unit
Event Timeline
libc/utils/CPP/Array.h | ||
---|---|---|
23–29 | 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 | ||
17 | You can use N everywhere, you don't need Length | |
23–29 | +1 | |
libc/utils/CPP/ArrayRef.h | ||
60 | That would be nice to have size_t available separately. | |
80 | [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 | ||
68 | Can we have an explicit specialization that handles comparing two bool? |
libc/utils/UnitTest/Test.h | ||
---|---|---|
21 | Now that I see it again, I think this should say "return bool" or "return _Bool" | |
68 | https://reviews.llvm.org/D73472#inline-667032 and line 20 of this file. |
libc/utils/CPP/ArrayRef.h | ||
---|---|---|
80 | 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 | ||
21 | Fixed this and other typos I found. | |
68 | 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!