Avoid use of string functions in constexpr context when the compiler can't support that
Summary: It's insufficient to infer support for `constexpr` `std::strlen` by merely testing that we're using libstdc++ on a compiler other than clang. Some other compilers besides gcc can be using libstdc++ that _don't_ have `constexpr` `std::strlen`. Rather, use the compiler itself to detect support for either (a) the builtins, or (b) a `constexpr` implementation of the stdlb function, falling back to a custom `constexpr` implementation otherwise. Also, handle MSVC, which supports `__builtin_strlen` but which doesn't support either `__has_feature` or `__has_builtin`. Give `constexpr_strcmp` the same handling, but leave MSVC out of the fun because it doesn't provide `__builtin_strcmp`. Also, remove the unnecessary include of `<type_traits>`. Finally, make these functions `noexcept` for good measure. Extra info: The overload sets in the `detail` namespace in this diff are a little magical. The first overload only compiles if (a) the string literal `"a"` can be `static_cast` to `const Char*` (that is, only if `Char` is `char`), and (b) if `FOLLY_DETAIL_STR???` yields a compile-time constant (so it can be used to initialize a non-type template parameter). If both of those things are true, that overload is preferred because the last argument requires no conversion. If either of those two conditions is false, that overload has a substitution failure and is removed from consideration. Then the second overload is selected. Reviewed By: yfeldblum Differential Revision: D23407997 fbshipit-source-id: f5838c578cb62b8fd777052223222882a6575429
Showing
Please register or sign in to comment