[Bug c++/113814] [modules] canonical types ICE with imported partial specialization matching existing template-id

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

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

--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:ff41862357ca2ea56177209a2e3b7d9c64bcfa8c

commit r14-8870-gff41862357ca2ea56177209a2e3b7d9c64bcfa8c
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Feb 7 14:24:51 2024 -0500

    libstdc++: Work around modules issue causing hello-1 ICE [PR113710]

    The forward declarations of std::get in <bits/stl_pair.h> added in
    r14-8710-g65b4cba9d6a9ff are causing an ICE in the test modules/hello-1
    due to what seems to be a declaration merging issue in modules.

    What's happening is that in hello-1_b.C we first include <string_view>,
    which indirectly includes <bits/stl_pair.h> which forms the dependent
    specialization tuple_element<__i, tuple<_Elements...>> (appearing in
    the signatures of some of the std::get overloads) and adds it to the
    specializations table.

    We then import hello which indirectly includes <tuple> (in the GMF),
    within which we define a partial specialization of tuple_element with
    that same template-id.  So importing hello in turn streams in this
    partial specialization but we don't merge it with the previously created
    dependent specialization, and we end up with two equivalent types for
    this template-id with different TYPE_CANONICAL.

    This patch works around this issue by adding a forward declaration of
    the tuple_element partial specialization from <tuple> to <bits/stl_pair.h>
    so that it appears alongside the dependent specialization of the same
    template-id.  So when including <bits/stl_pair.h> we immediately register
    the template-id as a partial specialization, and if we later stream in the
    partial specialization the MK_partial case of trees_in::key_mergeable will
    match them up.  (So perhaps a proper modules fix for this might be to make
    key_mergeable try to match up a streamed in partial specialization with an
    existing specialization from the table via match_mergeable_specialization.)

            PR testsuite/113710
            PR c++/113814

    libstdc++-v3/ChangeLog:

            * include/bits/stl_pair.h (tuple_element): Add forward
            declaration of the partial specialization for tuple.

    Reviewed-by: Jonathan Wakely <jwakely@redhat.com>