Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| clang/lib/AST/Interp/Context.h | ||
|---|---|---|
| 90 | Things like getGlobal() aren't const so that doesn't work. | |
| clang/lib/AST/Interp/Pointer.h | ||
| 340 | For primitive arrays, the elements don't have inline descriptors: Offset
│
▼
┌────────┬───┬───┬───┬───┬───┬─────┐
│InitMap │ 1 │ 2 │ 3 │ 4 │ 5 │ ... │
└────────┴───┴───┴───┴───┴───┴─────┘
▲
│
BaseIf the array elements are composite elements themselves however, we can have a pointer that refers to the array element: Offset
│
▼
┌──────────┬───┬──────────┬───┐
│InlineDesc│'a'│InlineDesc│'b'│
└──────────┴───┴──────────┴───┘
▲
│
Base(so things like isArrayElement() return true) as well as a pointer that _only_ refers to the composite element (after a call to narrow(): Offset
│
▼
┌──────────┬───┬──────────┬───┐
│InlineDesc│'a'│InlineDesc│'b'│
└──────────┴───┴──────────┴───┘
▲
│
BaseFor the latter, the expected value of getIndex() is 0, since it is (as far as the pointer knows) _not_ an array element. | |
| clang/lib/AST/Interp/Context.h | ||
|---|---|---|
| 90 | If this is only needed for testing, can we make it a private function and use friendship to expose it to just what needs it? (Esp because it's got some odd const-correctness properties to it.) | |
| clang/lib/AST/Interp/Pointer.h | ||
| 81–88 | Same here -- can these be private and friended? | |
| clang/lib/AST/Interp/Pointer.h | ||
|---|---|---|
| 81–88 | Don't you need a class to friend something? I only have the TEST(...) function in the unit test, so I can't do that, right? | |
| clang/lib/AST/Interp/Pointer.h | ||
|---|---|---|
| 81–88 | FRIEND_TEST does this, I believe: https://google.github.io/googletest/reference/testing.html#FRIEND_TEST | |
| clang/lib/AST/Interp/Pointer.h | ||
|---|---|---|
| 81–88 | Is this something we should be doing? There's nothing else in clang using FRIEND_TEST and only stuff in Testing/ includes gtest.h. | |
| clang/lib/AST/Interp/Pointer.h | ||
|---|---|---|
| 81–88 | It's a tradeoff as to whether we want to expose private implementation details as part of a public interface just to enable unit testing, or whether we want to sprinkle unit testing annotations around the private implementation details just to enable unit testing. Personally, I prefer having cleaner public interfaces; otherwise we end up with people using the implementation details of a class and it's harder to refactor in the future. I'm not certain how others feel, though. | |
| clang/lib/AST/Interp/Pointer.h | ||
|---|---|---|
| 81–88 | I think FRIEND_TEST just doesn't work because I can't import a gtest header from the clangAST library. What I can do is just wrap those things in a #ifdef IN_UNITTEST and define than before including those headers (all of this code is in headers right now) in the unittest/AST/Interp/Descriptor.cpp. | |
| clang/lib/AST/Interp/Pointer.h | ||
|---|---|---|
| 81–88 | Okay, that seems like a good compromise to me. Later, we might want to figure out if we can hoist the macro logic up to a higher level so that other interfaces can use the same pattern. (e.g., maybe we want LLVM_UNIT_TEST_INTERFACE macro or some such?) | |
| clang/unittests/AST/Interp/CMakeLists.txt | ||
|---|---|---|
| 2 | Why is this in a separate executable instead of in ASTTests? So it can have fewer deps? | |
| clang/unittests/AST/Interp/CMakeLists.txt | ||
|---|---|---|
| 2 | Mostly because running ASTTests takes very long | |
This should return a const ref