This revision introduces a new namespace, clang::transformer, to hold
the declarations for the Transformer library.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
WDYT about clang::transformer? I don't see much point in the intermediate namespace. However, LGTM either way.
Thanks for the review. I prefer clang::transformer but wasn't sure about ettiquete of introducing new namespaces under clang. If that's ok, then I'm happy to update.
I'm now starting to doubt the split into transformer (for combinators) and tooling (for the type decls). I checked and ast_matchers contains both. What do you think of my just putting all of the Transformer types + combis in the single clang::transformer namespace?
What do you think of my just putting all of the Transformer types + combis in the single clang::transformer namespace?
That would make sense to me.
This broke the modular build since some symbols are now ambiguous within the same Clang module.'
FAILED: tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Tooling -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include -Itools/clang/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/libxml2 -Iinclude -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include -Wdocumentation -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++14 -fmodules -fmodules-cache-path=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/module.cache -fcxx-modules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -fno-common -Woverloaded-virtual -Wno-nested-anon-types -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -UNDEBUG -fno-exceptions -fno-rtti -MD -MT tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o -MF tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o.d -o tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/AllTUsExecution.cpp.o -c /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp While building module 'Clang_Tooling' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp:9: In file included from <module-includes>:44: In file included from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/Transformer.h:14: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/RewriteRule.h:224:31: error: call to 'text' is ambiguous return change(std::move(S), text("")); ^~~~ /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/Stencil.h:145:13: note: candidate function StencilPart text(llvm::StringRef Text); ^ /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/include/clang/Tooling/Transformer/RewriteRule.h:35:22: note: candidate function inline TextGenerator text(std::string M) { ^ /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Tooling/AllTUsExecution.cpp:9:10: fatal error: could not build module 'Clang_Tooling' #include "clang/Tooling/AllTUsExecution.h" ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated.
Can you please fix and/or revert?
It looks like it's still failing: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2649/console
That line was fixed in the revision I mentioned: https://reviews.llvm.org/rL375003
Could it be that the bot hasn't picked up the revision yet?