Update coding standards for constexpr if statements; NFC

[aaron.ballman]

Summary

We currently suggest that users not use an else clause after a return statement in a prior if branch. e.g.,

if (foo)
  return 1;
else // Should remove this else clause
  return 10;

however, this suggestion is incorrect for a constexpr if statement because one of the two branches will be a discarded statement and thus can impact template instantiation behavior. This updates the coding standard to make it clear that it's okay to have a return after an else in a constexpr if statement.

I think this is an NFC change to the intent of the rule, which is why I've not started an RFC for the changes.

[erichkeane]

Agreed. For other reviewers, note that this is the compelling example:

template<typename T>
static constexpr bool VarTempl = true;

template<typename T>
int func() {
  if constexpr (VarTempl<T>)
    return 1;
  
  static_assert(!VarTempl<T>);
}

void use() {
    func<int>();
}

The static-assert would fail, since it isn't a discarded statement.

template<typename T>
static constexpr bool VarTempl = true;

template<typename T>
int func() {
  if constexpr (VarTempl<T>)
    return 1;
  else 
  static_assert(!VarTempl<T>);
}

void use() {
    func<int>();
}

But in THIS case the static-assert is discarded. That is, the 'else' in a if-constexpr isn't required to be anything other than lexically valid, so dependent lookup doesn't need to happen, instantiations aren't required, etc.

Therefore there is EXTREME value to having an 'else' there after a return.

[dblaikie]

Yeah, I'm OK with this, though yeah, having an example where the else is necessary, but I don't mind too much.

[aaron.ballman]

In D132232#3735911, @dblaikie wrote:

Yeah, I'm OK with this, though yeah, having an example where the else is necessary, but I don't mind too much.

I went ahead and switched the example to Erich's because it wasn't much longer than my example anyway. Thank you!

llvm/docs/CodingStandards.rst

if (Type.isNull()) {
                        ASTContext::GE_Missing_jmp_buf;
       return QualType();
     }
     break;
 
 The idea is to reduce indentation and the amount of code you have to keep track
 of when reading the code.
 
+Note: this advice does not apply to a ``constexpr if`` statement. The
+substatement of the ``else`` clause may be a discarded statement, so removing
+the ``else`` can cause unexpected template instantiations. Thus, the following
+example is correct:
+
+.. code-block:: c++
+
+  template<typename T>
+  static constexpr bool VarTempl = true;
+
+  template<typename T>
+  int func() {
+    if constexpr (VarTempl<T>)
+      return 1;
+    else
+      static_assert(!VarTempl<T>);
+  }
+
 Turn Predicate Loops into Predicate Functions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 It is very common to write small loops that just compute a boolean value.  There
 are a number of ways that people commonly write these, but an example of this
 sort of thing is:
 
 .. code-block:: c++