5 ms·

"Even now, clang cannot compile some of our C++ codebase." Andrei, I'm a bit surprised by this statement. Could you give an example? Otherwise great work.

Gownta 13y ago
Here's a gem that clang produces when compiling folly: "clang-3.4: error: unable to execute command: Segmentation fault"
- shin_lao 13y ago
  So we're not the only ones. We had to go back to Clang 3.3 because Clang 3.4 had issues with our meta-programming craziness. But still, I submit a clang-based tool is a better bet in the long run.
inglorion 13y ago
Here are some examples that we've run into in the past: Some of our code used GCC nested functions, which Clang did not support. We were using __sync_val_compare_and_swap with __int128 values, which wasn't supported by the Clang version we were using. I believe the current version of Clang supports this. Clang is stricter about some things than GCC, e.g. Clang doesn't like it when you declare a class as struct in one place and in a class in another place. I think there is also a difference where Clang deduces that your enum is unsigned if none of its declared values are negative, and warns you if you compare it < 0. Since we compile with -Werror, this will cause compilation to fail. None of these are unsurmountable, but they do mean we can't just drop in Clang and expect everything to work.
agame 13y ago
I believe clang also doesn't currently support the "ifunc" attribute, which we also use in a few places.
rquirk 13y ago
Not facebook examples, but things I've seen are as follows. All these were fixable to be correct for both GCC and Clang (it's worth it for the clang static analysis). GCC can call the base destructor explicitly in destructors (an error in clang). i.e. this->~BaseClass(); This is normally a coding error anyway, since the call is added by the compiler. You sometimes have to add this-> in templates to disambiguate which function is called. GCC has, or had, a better (different?) two-phase look up for templates, so you can #include a file after its template is used in another header. Clang is stricter and requires you #include "A.h" and #include "foo.h" before using A<foo>, even if the overall compilation unit does eventually declare the A template and the foo class. GCC supports variable length arrays, so you can do `MyClass x[someValue + 1];`, but with Clang you need to use a vector of MyClass, like vector<MyClass> x(someValue + 1). This sort of thing compiles in GCC, but not clang: template <typename T> class List : public list<T> {}; const List<string> tmpList; It is missing a default constructor, GCC finds one from somewhere :) GCC allows friends of derived classes to call static base class protected functions. i.e. Base::protectedFunc() can be called if the current class is a friend only of BaseSubclass. In clang you need to call BaseSubclass::protectedFunc(). Clang requires more explicit template instantiation to avoid link errors. Not sure exactly when, just "sometimes" and you'll know it when you see it :-) Then as mentioned elsewhere clang shouts a lot about mismatched forward declaration (struct vs class).

Gownta 13y ago

Here's a gem that clang produces when compiling folly: "clang-3.4: error: unable to execute command: Segmentation fault"

shin_lao 13y ago
So we're not the only ones. We had to go back to Clang 3.3 because Clang 3.4 had issues with our meta-programming craziness. But still, I submit a clang-based tool is a better bet in the long run.

inglorion 13y ago

Here are some examples that we've run into in the past: Some of our code used GCC nested functions, which Clang did not support. We were using __sync_val_compare_and_swap with __int128 values, which wasn't supported by the Clang version we were using. I believe the current version of Clang supports this. Clang is stricter about some things than GCC, e.g. Clang doesn't like it when you declare a class as struct in one place and in a class in another place. I think there is also a difference where Clang deduces that your enum is unsigned if none of its declared values are negative, and warns you if you compare it < 0. Since we compile with -Werror, this will cause compilation to fail. None of these are unsurmountable, but they do mean we can't just drop in Clang and expect everything to work.

agame 13y ago

I believe clang also doesn't currently support the "ifunc" attribute, which we also use in a few places.

rquirk 13y ago

Not facebook examples, but things I've seen are as follows. All these were fixable to be correct for both GCC and Clang (it's worth it for the clang static analysis). GCC can call the base destructor explicitly in destructors (an error in clang). i.e. this->~BaseClass(); This is normally a coding error anyway, since the call is added by the compiler. You sometimes have to add this-> in templates to disambiguate which function is called. GCC has, or had, a better (different?) two-phase look up for templates, so you can #include a file after its template is used in another header. Clang is stricter and requires you #include "A.h" and #include "foo.h" before using A<foo>, even if the overall compilation unit does eventually declare the A template and the foo class. GCC supports variable length arrays, so you can do `MyClass x[someValue + 1];`, but with Clang you need to use a vector of MyClass, like vector<MyClass> x(someValue + 1). This sort of thing compiles in GCC, but not clang: template <typename T> class List : public list<T> {}; const List<string> tmpList; It is missing a default constructor, GCC finds one from somewhere :) GCC allows friends of derived classes to call static base class protected functions. i.e. Base::protectedFunc() can be called if the current class is a friend only of BaseSubclass. In clang you need to call BaseSubclass::protectedFunc(). Clang requires more explicit template instantiation to avoid link errors. Not sure exactly when, just "sometimes" and you'll know it when you see it :-) Then as mentioned elsewhere clang shouts a lot about mismatched forward declaration (struct vs class).