clang++

I'm having an interesting problem. I'm compiling a toy compiler with clang++ -g -x c++ y.tab.c lex.yy.c semantic_actions.cpp -o parser -lfl In y.tab.c I included semantic_actios.hpp and the contents in semantic_actions.hpp are some method declarations that are used in y.tab.c . That compiles fine. However if I change it to clang++ -c -g -x c++ semantic_actions.cpp -o semantic_actions.o clang++ -g -x c++ y.tab.c lex.yy.c -o parser semantic_actions.o -lfl I see semantic_actions.o:1:1: error: source file is not valid UTF-8 <CF><FA><ED><FE><U+0007> ^ semantic_actions.o:1:2: error: source file is

Assuming this is possible, could someone tell me, how I have to configure the cmake build to create a "pure" llvm toolchain on ubuntu-16.04 consisting of clang lld libc++ libc++abi libunwind (llvm) compiler-rt any other pieces that might be relevant and are "production ready" The resulting compiler should be as fast as possible (optimizations turned on, no unnecessary asserts or other checks in the compiler binary itself) be installed in a separate, local directory (lets call it <llvm_install> ) not have dependencies to the llvm tolchain provided by packet manager use libc++, libc++abi etc by

I'm playing with c++11 and I came across a difference in behavior between g++ 4.9.2 and clang++ 3.5 (but only when it uses the libc++; when it uses the libstdc++, clang++ seems to behave as such as g++) related with a template template specialization for a template class. The following is a trivial example #include <set> template <typename X> class foo; template <template<typename, typename ...> class C, typename X> class foo<C<X>> {}; int main () { foo<std::set<int>> f; return 0; } g++ compiles without problems; clang++ compiles without problems with the libstdc++ but, adding -stdlib=libc++ ,

Background: Consider the following example : #include <iostream> #include <vector> int main() { std::vector<bool> vectorBool{false, true}; for(const auto &element : vectorBool) std::cout << std::boolalpha << element << ' '; return 0; } It emits the warning: test.cpp:6:21: warning: loop variable 'element' is always a copy because the range of type 'std::vector<bool>' does not return a reference [-Wrange-loop-analysis] for(const auto &element : vectorBool) std::cout << std::boolalpha << element << ' '; ^ test.cpp:6:9: note: use non-reference type 'std::_Bit_reference' for(const auto &element :

In his talk at CppCon, Richard Smith mentioned that even though the Module TS support is currently work in progress, it can already be used. So I build clang 4.0 from svn and tried it on a very simple example. In my myclass.cppm file I defined a simple wrapper for an int module myclass; export class MyClass { public: MyClass (int i) : _i{i} {} int get() { return _i; } private: int _i; }; and my main.cpp just creates one instance of that class and outputs its held int to std::cout . #include <iostream> #include <string> import myclass; int main(int, char**) { MyClass three{3}; std::cout << std:

I just installed ClangOnWin ,and I'm trying to get clang-tidy 's "modernize" checks to work. Unfortunately, clang-tidy doesn't seem to know about them: clang-tidy -list-checks foo.cpp -- | grep modernize produces no output. The "modernize" checks are listed here , but that page seems to document Clang 3.8, and the version I have installed is 3.7. However, version 3.7 is the current one listed at the LLVM Download Page . clang-tidy knows about a variety of security checks, so I think I have it installed correctly. For example, clang-tidy -list-checks foo.cpp -- | grep security yields this:

I ran into an interesting issue when trying to mix clang (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn, Target: x86_64-apple-darwin14.0.0), c++11 and CGAL (via MacPorts). It seems that whether or not I call std::vector<>::reserve will determine whether my program will even compile. I've trimmed down the problem into a minimal example (as minimal as CGAL examples get): #include <vector> #include <CGAL/Exact_predicates_inexact_constructions_kernel.h> #include <CGAL/AABB_tree.h> #include <CGAL/AABB_traits.h> #include <CGAL/AABB_triangle_primitive.h> // CGAL::Epeck works fine,