[PATCH] D144285: [Clang] Implement CWG2518 - static_assert(false)

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 23 06:50:46 PST 2023


aaron.ballman added a comment.

In D144285#4135807 <https://reviews.llvm.org/D144285#4135807>, @erichkeane wrote:

> In D144285#4135775 <https://reviews.llvm.org/D144285#4135775>, @Endill wrote:
>
>> Thank you for the patch.
>> Any plans to backport this to 16.x branch?
>
> I would not really want us to do that, the breaking change here is concerning, and I'd like this to spend time in trunk 'baking' a while.

+1, at this point the only things we should be backporting to 16.x are fixes for regressions or fixes for security concerns.



================
Comment at: clang/lib/Sema/SemaDeclCXX.cpp:16824-16841
       if (InnerCond && isa<ConceptSpecializationExpr>(InnerCond)) {
         // Drill down into concept specialization expressions to see why they
         // weren't satisfied.
         Diag(StaticAssertLoc, diag::err_static_assert_failed)
           << !AssertMessage << Msg.str() << AssertExpr->getSourceRange();
         ConstraintSatisfaction Satisfaction;
         if (!CheckConstraintSatisfaction(InnerCond, Satisfaction))
----------------
cor3ntin wrote:
> rsmith wrote:
> > I wonder if it's worth adding a custom diagnostic (eg, "this template cannot be instantiated: %0") for the case where we're in template instantiation and the expression is the bool literal `false`.
> I'm not sure i see the motivation. Why would we want to special case `false`? The expression could also be an always false, never dependent expression
Richard may have different ideas in mind, but the motivation to me is code like: 
```
template <typename Ty>
struct S {
  static_assert(false, "you have to use one of the valid specializations, not the primary template");
};

template <>
struct S<int> {
};

template <>
struct S<float> {    
};

int main() {
  S<int> s1;
  S<float> s2;
  S<double> s3;
}
```
Rather than telling the user the static_assert failed because false is not true, having a custom diagnostic might read better for users. GCC doesn't produce a custom diagnostic -- the behavior isn't terrible, but the "false evaluates to false" note is effectively just noise, too: https://godbolt.org/z/456bzWG7c


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144285/new/

https://reviews.llvm.org/D144285



More information about the cfe-commits mailing list