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 │ ... │ └────────┴───┴───┴───┴───┴───┴─────┘ ▲ │ Base If 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'│ └──────────┴───┴──────────┴───┘ ▲ │ Base For 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