Re: Refactor compile-time assertion checks for C/C++

On Sat, Mar 21, 2020 at 07:22:41PM -0400, Tom Lane wrote:
> which of course is pointing at
>
>     StaticAssertStmt(((int64) -1 >> 1) == (int64) -1,
>                      "arithmetic right shift is needed");
>
> so the existing "C and C++" fallback StaticAssertStmt doesn't work for
> older g++.  (This is g++ 4.4.7 from RHEL6.)

Hmm.  Thanks.  I just have an access down to 7.5 on my machine.

> Huh?  Surely do{} is a legal statement.

Yep, still my VS-2015 compiler complains when using the fallback with
do{} for statements, and I am not sure why.  An extra choice coming to
my mind would be to use a more native MS implementation, as documented
here:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/assert-asserte-assert-expr-macros?view=vs-2019
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/static-assert-macro?view=vs-2019

This requires an extra branch in our implementation set which is not
really appealing, with I guess the following mapping (not tested):
- _STATIC_ASSERT for StaticAssertDecl and StaticAssertExpr.
- _ASSERT_EXPR for and StaticAssertStmt.
I think that one advantage is that this would allow to simplify the
fallback implementations for C/C++ to use do{}s.

> Maybe we should just revert b7f64c64d instead of putting more time
> into this.  It's looking like we're going to end up with four or so
> implementations no matter what, so it's getting hard to see any
> real benefit.

Indeed.  I have tried a couple of other things I could think of, but I
cannot really get down to 3 implementations, so there is no actual
benefit.

I have done a complete revert to keep the history cleaner for release
notes and such, including this part:
- * On recent C++ compilers, we can use standard static_assert().
Don't you think that we should keep this comment at the end?  It is
still true.

Thanks for the discussion!
--
Michael