This patch adds support for matching gtest's ASSERT_THAT, EXPECT_THAT, ON_CALL and EXPECT_CALL macros.
Details
Diff Detail
Unit Tests
Time | Test | |
---|---|---|
6,500 ms | x64 debian > libarcher.races::lock-unrelated.c |
Event Timeline
clang/include/clang/ASTMatchers/GtestMatchers.h | ||
---|---|---|
34 | worth comments. out of curiosity, what do we call this Matchers? I'd be careful to introduce a different matcher concept in the ast_matcher library, it would easily cause confusion. | |
39 | as we add a new method to handle ASSERT_THAT, this comment is not clear enough to me, ASSERT_... makes me think ASSERT_THAT is included as well. I would suggest rephrase the comment (explicitly mentioning this is for comparison operations, IIUC), and even rename the method to gtestAssertCmp (we can defer it to a follow-up patch). | |
40 | nit: I would reorder APIs in these file, grouping by assert, expect, oncall. ...gtestAssert(); ...gtestAssertThat(); ...gtestExpect(); ...gtestExpectThat(); ...gtestExpectCall(); | |
81 | this comment doesn't seem to express enough information, what's the difference from the above one? I think adding an example would be helpful. | |
clang/lib/ASTMatchers/GtestMatchers.cpp | ||
41 | why remove this llvm_unreachable? I think this is a common practice in LLVM. | |
47 | the static qualifier is not needed as you wrap it within an anonymous namespace. the same below. | |
86 | worth comments on these magic string come from -- gtest library? | |
104 | As the function creates an AST matcher to match the gtest method, 'd rename the function name like gtestComparisonIMatcher, the same to following functions. | |
135 | I believe this is something related to the gtest internal implementation, could you add a comment to explain that? | |
clang/unittests/ASTMatchers/GtestMatchersTest.cpp | ||
330 | nit: bind is not needed? |
clang/include/clang/ASTMatchers/GtestMatchers.h | ||
---|---|---|
34 | +1 Please move the comments relating to this enum from the two gtestOnCall functions to here. hokein@ -- the "Matchers" is because its describing googletest matchers. But, it is a bit confusing in this context and doesn't really add anything. What do you think of None and Some instead? | |
55–59 | Please move this to a comment describing the MockArgs enum. | |
clang/lib/ASTMatchers/GtestMatchers.cpp | ||
47 | nit: per the style guide (https://releases.llvm.org/2.7/docs/CodingStandards.html#micro_anonns), I think it would be better to shrink the anonymous namespace to only enclose the enum decl, and keep these static annotations and in fact add a few that are currently missing on the gtestCallInternal functions. |
clang/include/clang/ASTMatchers/GtestMatchers.h | ||
---|---|---|
39 | I changed the comment to make it more accurate. ymandel@ and I talked about rename the APIs but we weren't sure if it is worth it as it may break some code. I would like to at least defer that to another patch. | |
81 | The difference between the two gtestExpectCall overloads is just like the difference between the two gtestOnCall overloads. | |
clang/lib/ASTMatchers/GtestMatchers.cpp | ||
41 | ymandel@ suggested me removing it as the switch covers all the possible values of the enum. | |
47 | I changed the code following ymandel@'s suggestion. | |
clang/unittests/ASTMatchers/GtestMatchersTest.cpp | ||
330 | Just wanted to illustrate the usage here. |
a few more nits, the code looks good to me now. As discussed with @ymandel offline, we should be aware of that before moving forward to this direction -- this patch will likely have the gtest-versioning issue.
clang/lib/ASTMatchers/GtestMatchers.cpp | ||
---|---|---|
41 | either seems fine to me (this is just a coding style), I think the problem is that we have inconsistencies in the patch - e.g. on Line95, default: llvm_unreachable, we should stick with one style. | |
104 | this comment seems undone. | |
128 | I think For example, ... words are implementation details, should move to the corresponding switch case below. |
worth comments.
out of curiosity, what do we call this Matchers? I'd be careful to introduce a different matcher concept in the ast_matcher library, it would easily cause confusion.