[cfe-dev] A problem with forEachConstructorInitializer
Manuel Klimek
klimek at google.com
Fri Sep 27 23:50:39 PDT 2013
If you're using matchers, I strongly suggest to use clang's trunk...
On Fri, Sep 27, 2013 at 9:47 AM, Pedro Delgado Perez
<pedro.delgado at uca.es>wrote:
> Yes, for instance, I ported back the matcher parmVarDecl and it seemed
> to work fine (although right now is not working in the matcher
>
> recordDecl(hasMethod(has(parmVarDecl(hasName("x")))))
>
> and I don't know why).
>
> However, it seems not possible to port back the matchers ctorInitializer
> or forEachConstructorInitializer as some files need to be changed... and
> this is a problem to me.
> 1. Is there a site where I can find the steps to correctly update clang to
> the version 3.4?
> 2. Has anyone been able to fix at least these matchers?
>
> Thanks,
>
> Pedro.
>
> *El día 26 sep 2013 23:54, Gabor Kozar <kozargabor at gmail.com> escribió:*
>
> In general you can't just go around updating random Clang files in hopes
> of getting some select new features. You should seriously consider either
> moving to the trunk version, or just porting back the required features.
> Sometimes though it's just not possible, because a feature e.g. relies on
> structural support from the system - for instance, I was looking at trying
> to port back equalsBoundNode() to Clang 3.3, but it's not possible.
>
> So your best bet is probably looking at the implementation of the new
> Clang 3.4 features you want to use with your older version, and try to
> figure out if it can be ported back... Matchers usually can be.
>
> --
> Gábor Kozár -- ShdNx
> kozargabor at gmail.com
>
>
>
> On Thu, Sep 26, 2013, at 17:01, Pedro Delgado Perez wrote:
>
> Your issue is most confusing. You will need to show us the matcher code
> you're trying to get working.
>
> I've been looking for the 'forEachConstructorInitializer' and it wasn't
> in ASTMatchers.h. I've been trying to replace these files(macros, internal,
> matchfinder...) for the ones in the svn, but it didn't work.
>
> I don't want you to be thinking on the matcher, but my matcher, trying to
> bind every constructor initializer for fields in the class, is:
>
> constructorDecl(
> isDefinition(),
> anyOf(
> hasAnyConstructorInitializer(isWritten()),
> has(compoundStmt(has(stmt())))
> ),
>
> forEachConstructorInitializer(forField(decl().bind("CI")))
> );
>
> I have tried to change 'forEachConstructorInitializer' for
> 'forEach(ctorInitializer)', but the system can't identify ctorInitializer
> neither! :S
>
> As for your build issues: try doing a clean rebuild, i.e. reconfigure (or
> run cmake again), and then make. I have never used ninja, so no idea if the
> issue could be on that front. Also make sure that you've not accidentally
> corrupted your LLVM/Clang checkout... But I hope you already tried these.
>
> I don't know why, but if I run ninja with "sudo", it works fine now.
> *El día 26 sep 2013 14:28, Gabor Kozar <kozargabor at gmail.com> escribió:*
>
> Replying on cfe-dev.
>
> Your issue is most confusing. You will need to show us the matcher code
> you're trying to get working.
>
> By the way, you do not need to place your own matchers in ASTMatchers.h,
> you can create an own header file, like so:
>
> #include "clang/ASTMatchers/ASTMatchersMacros.h"
> #include "clang/ASTMatchers/ASTMatchersInternal.h"
>
> namespace clang {
> namespace ast_matchers {
>
> // your matchers here
>
> } // end namespace ast_matchers
> } // end namespace clang
>
> Do not forget the header guard of course and anything else you may need.
>
> As for your build issues: try doing a clean rebuild, i.e. reconfigure (or
> run cmake again), and then make. I have never used ninja, so no idea if the
> issue could be on that front. Also make sure that you've not accidentally
> corrupted your LLVM/Clang checkout... But I hope you already tried these.
>
> --
> Gábor Kozár -- ShdNx
> kozargabor at gmail.com
>
>
>
> On Thu, Sep 26, 2013, at 11:29, Pedro Delgado Perez wrote:
>
> Hi Gábor,
>
> Sorry to write you directly, but I don't know why I can't post messages in
> cfe-dev...
>
> I get through you because, some months ago, you told me what could I do
> when a matcher in http://clang.llvm.org/docs/LibASTMatchersReference.html
> was no present in my ASTMatchers.h.
>
> Now, I'm trying to integrate the matcher forEachConstructorInitializer in
>
> http://llvm.org/svn/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
>
> Firstly, I have included it in my ASTMatchers, but I don't know why the
> system is not recognizing this new matcher. So I have put it in my own
> source file. Now, the system gives me the next problem and I would like to
> know how could I solve this:
>
> CTD_operator.cpp:42:29: error: calling a private constructor of class
> 'clang::ast_matchers::internal::BoundNodesTreeBuilder'
> BoundNodesTreeBuilder InitBuilder(*Builder);
> ^
> /usr/local/include/clang/ASTMatchers/ASTMatchersInternal.h:178:3: note:
> declared private here
> BoundNodesTreeBuilder(const BoundNodesTreeBuilder &)
> LLVM_DELETED_FUNCTION;
> ^
> CTD_operator.cpp:45:25: error: no viable conversion from
> 'clang::ast_matchers::internal::BoundNodesTreeBuilder' to 'const
> clang::ast_matchers::internal::BoundNodesTree'
> Result.addMatch(InitBuilder);
> ^~~~~~~~~~~
> /usr/local/include/clang/ASTMatchers/ASTMatchersInternal.h:113:7: note:
> candidate constructor (the implicit copy constructor) not viable: no known
> conversion from
> 'clang::ast_matchers::internal::BoundNodesTreeBuilder' to 'const
> clang::ast_matchers::internal::BoundNodesTree &' for 1st argument
> class BoundNodesTree {
> ^
> /usr/local/include/clang/ASTMatchers/ASTMatchersInternal.h:172:39: note:
> passing argument to parameter 'Bindings' here
> void addMatch(const BoundNodesTree& Bindings);
> ^
> CTD_operator.cpp:48:14: error: 'operator=' is a private member of
> 'clang::ast_matchers::internal::BoundNodesTreeBuilder'
> *Builder = Result;
> ~~~~~~~~ ^ ~~~~~~
> /usr/local/include/clang/ASTMatchers/ASTMatchersInternal.h:179:8: note:
> declared private here
> void operator=(const BoundNodesTreeBuilder &) LLVM_DELETED_FUNCTION;
> ^
>
>
> Should I also change ASTMatchersInternal.h?? Do you recommend me to
> replace these header files for the last version?
>
> How can I achieve that the system is aware of the changes I introduce in
> these files? I have a Makefile and only write "make" from the shell...
> Since two days ago, I was using ninja, but I don't know why, suddenly,
> start giving this fail:
>
> pedro at hal ~/clang-llvm/build $ ninja
>
> [6/745] Building CXX object
> lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/HexagonRemoveSZExtArgs.cpp.o
> FAILED: /usr/local/bin/clang++ -D_DEBUG -D_GNU_SOURCE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dtor -fcolor-diagnostics -fno-rtti
> -Ilib/Target/Hexagon -I/home/pedro/clang-llvm/llvm/lib/Target/Hexagon
> -Iinclude -I/home/pedro/clang-llvm/llvm/include -fno-exceptions
> -fno-exceptions -MMD -MT
> lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/HexagonRemoveSZExtArgs.cpp.o
> -MF
> "lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/HexagonRemoveSZExtArgs.cpp.o.d"
> -o
> lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/HexagonRemoveSZExtArgs.cpp.o
> -c /home/pedro/clang-llvm/llvm/lib/Target/Hexagon/HexagonRemoveSZExtArgs.cpp
> error: unable to open output file
> 'lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/HexagonRemoveSZExtArgs.cpp.o':
> 'Error opening output file
> 'lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/HexagonRemoveSZExtArgs.cpp.o''
> 1 error generated.
> [6/745] Linking CXX static library lib/libLLVMInstrumentation.a
> ninja: build stopped: subcommand failed.
>
>
> I don't know what is "HexagonRemoveSZExtArgs.cpp.o" :S
>
> Thanks,
>
> Pedro.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130928/79107967/attachment.html>
More information about the cfe-dev
mailing list