Interpret strlen as constexpr for GCC Compatibility

[erichkeane]

Summary

GCC (and other compilers) treat strlen as a 'constexpr' function as an extension to the language. Clang previously treated builtin_strlen as a constexpr extension, so for this patch it was only necessary to remove the error-causing diagnostic for the strlen case, which falls through to the builtin_strlen handling.

Additionally, the strlen test previously expected this error, so this patch removes the error-expectation from the test.

[rsmith]

This is not a conforming extension. We are explicitly not allowed to make standard library functions constexpr if the standard doesn't say they are; see [constexpr.functions] (17.6.5.6) in the C++ standard. Clang previously used to allow constant-folding strlen calls, but we removed that support intentionally for this reason.

It would seem reasonable for this constant-folding to be enabled for strlen if the callee was explicitly marked as constexpr in the source code. That way, if the standard library chooses to mark it as constexpr as a (currently) non-conforming extension, we would provide an optimized implementation.

[erichkeane]

In D23692#520081, @rsmith wrote:

This is not a conforming extension. We are explicitly not allowed to make standard library functions constexpr if the standard doesn't say they are; see [constexpr.functions] (17.6.5.6) in the C++ standard. Clang previously used to allow constant-folding strlen calls, but we removed that support intentionally for this reason.

It would seem reasonable for this constant-folding to be enabled for strlen if the callee was explicitly marked as constexpr in the source code. That way, if the standard library chooses to mark it as constexpr as a (currently) non-conforming extension, we would provide an optimized implementation.

Ok, thank you for your prompt response. I'll see if that is a viable solution for this case.

Thanks!

[erichkeane]

In D23692#520097, @erichkeane wrote:

In D23692#520081, @rsmith wrote:

This is not a conforming extension. We are explicitly not allowed to make standard library functions constexpr if the standard doesn't say they are; see [constexpr.functions] (17.6.5.6) in the C++ standard. Clang previously used to allow constant-folding strlen calls, but we removed that support intentionally for this reason.

It would seem reasonable for this constant-folding to be enabled for strlen if the callee was explicitly marked as constexpr in the source code. That way, if the standard library chooses to mark it as constexpr as a (currently) non-conforming extension, we would provide an optimized implementation.

Ok, thank you for your prompt response. I'll see if that is a viable solution for this case.

Thanks!

Sadly, it doesn't seem that this would be a viable fix. libstdc++ doesn't actually seem to implement strlen, and all references to it are "extern size_t strlen", with no constexpr. I suspect they are doing what I did here, just treating it as constexpr as a special function. As mentioned, I didn't even see an implementation at all, so I think they're counting on the compiler replacing it with the built-in immediately anyway.

lib/AST/ExprConstant.cpp

   }
 
   case Builtin::BIstrlen:
-    // A call to strlen is not a constant expression.
-    if (Info.getLangOpts().CPlusPlus11)
-      Info.CCEDiag(E, diag::note_constexpr_invalid_function)
-        << /*isConstexpr*/0 << /*isConstructor*/0 << "'strlen'";
-    else
+    // As a GCC compatibility extension, we support strlen() 
+    // as a constant expression.
+    if (!Info.getLangOpts().CPlusPlus11)
       Info.CCEDiag(E, diag::note_invalid_subexpr_in_const_expr);
     // Fall through.
   case Builtin::BI__builtin_strlen: {

test/SemaCXX/constexpr-strlen.cpp

 
 # 10 "SemaCXX/constexpr-strlen.cpp" 2
 constexpr int n = __builtin_strlen("hello"); // ok
-constexpr int m = strlen("hello"); // expected-error {{constant expression}} expected-note {{non-constexpr function 'strlen' cannot be used in a constant expression}}
+constexpr int m = strlen("hello"); // ok
 
 // Make sure we can evaluate a call to strlen.
 int arr[3]; // expected-note {{here}}