Rejects-valid with static_assert referring to templated array variable with incomplete bound

[efriedma-quic]

template<int x> int a[] = {1,2,3};
static_assert(a<1> + 1 - a<1> == 1);

<source>:2:15: error: static assertion expression is not an integral constant expression
    2 | static_assert(a<1> + 1 - a<1> == 1);
      |               ^~~~~~~~~~~~~~~~~~~~
<source>:2:20: note: indexing of array without known bound is not allowed in a constant expression
    2 | static_assert(a<1> + 1 - a<1> == 1);
      |                    ^
1 error generated.

This seems wrong; I think referring to the array like this should force the computation of the correct type.

[zygoloid]

That does seem much simpler. The language rules aren't especially clear on when we're allowed to perform the instantiation of the initializer (see https://eel.is/c++draft/temp.inst#7) -- this hinges on whether the type of a<1> "affects the semantics of the program". (And in general we need to instantiate the initializer to determine the array bound, due to the possibility of brace elision and pack expansion.)

Other implementations seem to instantiate as soon as the variable is mentioned, whereas Clang tries to wait until it sees a use that actually depends on the array bound. I think the approach taken by the other compilers is reasonable -- the type of the expression naming the variable depends on the array bound, and that's part of the program semantics -- but I've emailed CWG to check and hopefully get the standard clarified.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Eli Friedman (efriedma-quic)

``` template<int x> int a[] = {1,2,3}; static_assert(a<1> + 1 - a<1> == 1); ```

<source>:2:15: error: static assertion expression is not an integral constant expression
    2 | static_assert(a<1> + 1 - a<1> == 1);
      |               ^~~~~~~~~~~~~~~~~~~~
<source>:2:20: note: indexing of array without known bound is not allowed in a constant expression
    2 | static_assert(a<1> + 1 - a<1> == 1);
      |                    ^
1 error generated.

This seems wrong; I think referring to the array like this should force the computation of the correct type.