[clang] consteval constructor executes at runtime when invoked by escalated immediate function (or fails to link)

[rkjnsn]

Consider the following code:

#include <iostream>
#include <optional>


class ConstEval {
 public:
  consteval ConstEval(const char* value) {
    const char* current_char = value;
    while (*current_char) {
      if (*current_char == 'a') {
        throw "Disallowed character!";
      }
      ++current_char;
    }
    value_ = value;
  }
  constexpr const char* value() { return value_; }
 private:
  const char* value_;
};

void TakesOptional(std::optional<ConstEval> maybe_value) {
  if (maybe_value.has_value()) {
    std::cout << "Value: " << maybe_value->value() << std::endl;
  } else {
    std::cout << "No value" << std::endl;
  }
}

int main(int argc, const char*argv[]) {
  // 1
  TakesOptional("testing 123");
  // 2
  std::optional<ConstEval> foo2 = "testing 123";
  // 3
  constexpr std::optional<ConstEval> foo3 = "testing 123";
  // 4
  TakesOptional(ConstEval{"testing 123"});
}

// 5
std::optional<ConstEval> foo5 = "testing 123";
// 6
constinit std::optional<ConstEval> foo6 = "testing 123";

Assuming I'm reading things correctly, I would expect the std::optional constructor to be an immediate-escalating function (because it is "a function that results from the instantiation of a templated entity defined with the constexpr specifier"), and a contained call to ConstEval's constructor to be an immediate-escalating expression, causing the std::optional constructor to become an immediate function.

Thus, I would expect lines 1, 2, 3, 5, and 6 all to immediately invoke the std::optional constructor to create a compile-time constant std::optional (indirectly invoking the ConstEval constructor), while 4 would immediately invoke the ConstEval constructor to create a constant ConstEval, which would then passed to the (not immediate, in this case) std::optional constructor.

Given that, I would further expect that changing "testing" to "tasting" on any of the 6 lines would result in a compiler failure (specifically, one informing me that throw "Disallowed character!" is not valid in a constant expression).

However, with clang built from revision 3dbd929, only lines 3, 4, and 6 fail to compile if "testing" is changed to "tasting". Lines 1, 2, and 5 unexpectedly continue to compile if "testing" in changed to "tasting", and instead cause an abort at runtime due to the uncaught exception. Thus, it appears that while clang properly considers the invocation of the explicitly-immediate ConstEval constructor to be a constant expression in 4, it erroneously does not consider the invocation of the escalated-to-immediate std::optional constructor to be a constant expression in 1, 2, and 5. Meanwhile, 3 and 6 invoke the constructor within an explicit constant expression, so those work as expected.

A further note: the observed behavior of ConstEval's constructor executing (and crashing if "testing" is changed to "tasting") at runtime for 1, 2, and 5 appears only to happen if it's small enough to inline into the generated std::optional specialization. If the constructor is more complicated and doesn't get inlined, lines 1, 2, and 5 will instead generate a linker error due to the symbol ConstEval::ConstEval(char const*) not being defined.

[efriedma-quic]

Needs reduced testcase that doesn't involve the full std::optional. (Looked briefly, but the issue seems to be deep inside the constructor for std::optional.)

[rkjnsn]

Unfortunately, the issue doesn't reproduce with a simple optional analog, so it's something within the complexity of std::optional's implementation that is triggering the bug.

[efriedma-quic]

class ConstEval {
 public:
  consteval ConstEval(const char* value) {
    throw "Disallowed character!";
  }
};
struct FakeOptionalBase {
    ConstEval val;
    template <class Anything = int> constexpr
    FakeOptionalBase(const char (&arg)[12]) : val(arg) {}
};
struct FakeOptional : FakeOptionalBase {
    using FakeOptionalBase::FakeOptionalBase;
};
void TakesOptional(FakeOptional maybe_value) {
}
int main(int argc, const char*argv[]) {
  TakesOptional(FakeOptional("tasting 123"));
}

[efriedma-quic]

The key here seems to be that the inherited constructor isn't marked as an immediate function in the AST.

[efriedma-quic]

(CC @cor3ntin)

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Erik Jensen (rkjnsn)

Consider the following code:

#include <iostream>
#include <optional>


class ConstEval {
 public:
  consteval ConstEval(const char* value) {
    const char* current_char = value;
    while (*current_char) {
      if (*current_char == 'a') {
        throw "Disallowed character!";
      }
      ++current_char;
    }
    value_ = value;
  }
  constexpr const char* value() { return value_; }
 private:
  const char* value_;
};

void TakesOptional(std::optional<ConstEval> maybe_value) {
  if (maybe_value.has_value()) {
    std::cout << "Value: " << maybe_value->value() << std::endl;
  } else {
    std::cout << "No value" << std::endl;
  }
}

int main(int argc, const char*argv[]) {
  // 1
  TakesOptional("testing 123");
  // 2
  std::optional<ConstEval> foo2 = "testing 123";
  // 3
  constexpr std::optional<ConstEval> foo3 = "testing 123";
  // 4
  TakesOptional(ConstEval{"testing 123"});
}

// 5
std::optional<ConstEval> foo5 = "testing 123";
// 6
constinit std::optional<ConstEval> foo6 = "testing 123";

Assuming I'm reading things correctly, I would expect the std::optional constructor to be an immediate-escalating function (because it is "a function that results from the instantiation of a templated entity defined with the constexpr specifier"), and a contained call to ConstEval's constructor to be an immediate-escalating expression, causing the std::optional constructor to become an immediate function.

Thus, I would expect lines 1, 2, 3, 5, and 6 all to immediately invoke the std::optional constructor to create a compile-time constant std::optional (indirectly invoking the ConstEval constructor), while 4 would immediately invoke the ConstEval constructor to create a constant ConstEval, which would then passed to the (not immediate, in this case) std::optional constructor.

Given that, I would further expect that changing "testing" to "tasting" on any of the 6 lines would result in a compiler failure (specifically, one informing me that throw "Disallowed character!" is not valid in a constant expression).

However, with clang built from revision 3dbd929, only lines 3, 4, and 6 fail to compile if "testing" is changed to "tasting". Lines 1, 2, and 5 unexpectedly continue to compile if "testing" in changed to "tasting", and instead cause an abort at runtime due to the uncaught exception. Thus, it appears that while clang properly considers the invocation of the explicitly-immediate ConstEval constructor to be a constant expression in 4, it erroneously does not consider the invocation of the escalated-to-immediate std::optional constructor to be a constant expression in 1, 2, and 5. Meanwhile, 3 and 6 invoke the constructor within an explicit constant expression, so those work as expected.

A further note: the observed behavior of ConstEval's constructor executing (and crashing if "testing" is changed to "tasting") at runtime for 1, 2, and 5 appears only to happen if it's small enough to inline into the generated std::optional specialization. If the constructor is more complicated and doesn't get inlined, lines 1, 2, and 5 will instead generate a linker error due to the symbol ConstEval::ConstEval(char const*) not being defined.