[Bug libstdc++/107376] regex executor requires allocator to be default constructible

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107376

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks for the report. The patch is necessary, but not sufficient.

We should probably have used the same allocator for _M_rep_count but doing that
now would be an ABI break.

We should definitely have used the same allocator for _M_states, and for its
_ResultsVec members, which would also be an ABI break, but we can mitigate that
with:

--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -124,9 +124,10 @@ namespace __detail
            break;
          std::fill_n(_M_states._M_visited_states, _M_nfa.size(), false);
          auto __old_queue = std::move(_M_states._M_match_queue);
+         auto __alloc = _M_cur_results.get_allocator();
          for (auto& __task : __old_queue)
            {
-             _M_cur_results = std::move(__task.second);
+             _M_cur_results = _ResultsVec(std::move(__task.second), __alloc);
              _M_dfs(__match_mode, __task.first);
            }
          if (__match_mode == _Match_mode::_Prefix)

With this change and the original patch suggestion, _M_cur_results always has
the same allocator as _M_results and so _Executor::_M_handle_accept won't
replace the allocator in _M_results when assigning the new results to it.

We could also use the same allocator for the local vector here:

    bool _Executor<_BiIter, _Alloc, _TraitsT, __dfs_mode>::
    _M_lookahead(_StateIdT __next)
    {
      // Backreferences may refer to captured content.
      // We may want to make this faster by not copying,
      // but let's not be clever prematurely.
      _ResultsVec __what(_M_cur_results);

Or we can rely on select_on_container_copy_construction() to do "the right
thing". Users of non-propagating allocators would probably prefer that, but it
means that matching with std::pmr::match_results will always use new/delete for
allocating intermediate results. But that's just one of the costs of the PMR
design.