[PATCH] D133801: Extraction of a matcher for an unused value from an expression from the bugprone-unused-return-value check

Fri Sep 23 20:33:28 PDT 2022

barcisz added inline comments.

================
Comment at: clang-tools-extra/unittests/clang-tidy/MatchersTest.cpp:2
+#include "utils/Matchers.h"
+#include "../../clang/unittests/ASTMatchers/ASTMatchersTest.h"
+
----------------
njames93 wrote:
> kwk wrote:
> > njames93 wrote:
> > > @kwk I seem to recall you saying in another patch that this include will break standalone builds, would stripping the leading `../../` work?
> > > @kwk I seem to recall you saying in another patch that this include will break standalone builds, 
> > 
> > @njames93 that's correct. But I don't recall the patch ID :/
> > 
> > > would stripping the leading `../../` work?
> > 
> > I don't know if the file is found then but it would make standalone builds certainly easier.
> > 
> > I'm not sure if I calculate correctly but given:
> > 
> > `clang-tools-extra/unittests/clang-tidy/MatchersTest.cpp`
> > 
> > then `../../` means `clang-tools-extra/`, no? If so, that directory doesn't contain a `clang` directory here. It seems as if the `../../` is relative to some other directory but not this file. Or am I too tired to get it?
> > 
> I'll test when I get a few cycles. If not, may need to copy some of the testing logic for this.
Yes, the tests do indeed work but it's probably because it's getting the include path from another directory. I was actually thinking of adding the directory for clang as an include path within cmake but thought this would be better. There is also an option of copying the testing setup from clang and pasting it here, or to just create testing checks and use the existing check testing utilities to run the matchers inside of those checks. What do you reckon is the best solution in that case to the problem of standalone builds?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133801/new/

https://reviews.llvm.org/D133801