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