<xstring>: constexpr string does not compile with -d1initall

[tiagomacarios]

The following code stopped compiling when d1initall is enabled.
https://godbolt.org/z/9EW3z1s5P

#include <string>

constexpr bool f() noexcept {
    std::string gate_name{"aaaaaaaaaaaaaaaaaaaaaa"};
    return true;
}

constexpr bool b = f();

Godbolt shows the regression starting in v19.38. Cameron helped me track the regression to PR 490538: Port 14 GitHub PRs: GH-3939, GH-3900, GH-3935, GH-3912, GH-3927, GH-3936, GH-3862, GH-3903, GH-3904, GH-3920, GH-3921, GH-3930, GH-3933, GH-3934.

[AlexGuteniev]

Suspect this is GH-3862 , and in particular this uninitialized pointer:

STL/stl/inc/xstring

Lines 2618 to 2624 in d6efe94

	pointer _Fancy_ptr;
	if constexpr (_Policy == _Allocation_policy::_At_least) {
	_Fancy_ptr = _Allocate_at_least_helper(_Al, _Capacity);
	} else {
	_STL_INTERNAL_STATIC_ASSERT(_Policy == _Allocation_policy::_Exactly);
	_Fancy_ptr = _Al.allocate(_Capacity);
	}

The -d1initall1023 -d1initAll:FillPatternE switches don't like that

[tiagomacarios]

Your suggested fix works.
We are currently using 19.38.33135 which ICEs with the fix. The last released version 19.39.33522 works correctly.

[CaseyCarter]

The following code stopped compiling when d1initall is enabled. https://godbolt.org/z/9EW3z1s5P

Well, I suppose it's a good thing that option isn't documented, or we'd have a bug! =P

[AlexGuteniev]

It looks like that it is a bug in these options, I'd expect delay initialized pointer to compile

[frederick-vs-ja]

Reduced example (Godbolt link)

constexpr bool fun()
{
    char* p [[maybe_unused]];
    return true;
}

constexpr bool b = fun();

Filed DevCom-10614520.

[AlexGuteniev]

DevCom-10614520 is Fixed - pending release.

Should we keep the initialization or pull it out later?

[tiagomacarios]

Just keep it.