https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275
--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to Nathaniel Shead from comment #4) > I suspect there are a number of issues tied together here. Some of the > things I've discovered so far: > > - 'tsubst_friend_class' calls 'lookup_name', which when called from a module > that doesn't export the class that was befriended fails to find it, and so > it substitutes in a new instance of that type (which then later fails > duplicate_decls). > > - Instantiating an elaborated type specifier doesn't attach it to the module > the containing template was declared in. Nathan's comments from the threads https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603288.html https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611215.html seem relevant here. > > - Sometimes it seems that the container of a MK_local_friend decl is not > always correctly streamed: in particular, in the comment 2 testcase the > container streamed is a complete type on write, but on read is not complete > (TYPE_SIZE is null) and so is not properly read on stream-in in the first > place. Interesting, it looks like the definition does eventually get streamed in but only after streaming in the MK_local_friend decl. MK_field decls seem to get streamed in beforehand too. > > Additionally, it looks like you can hide some of the errors by making the > importer a named module, because on instantiation it only calls > 'duplicate_decls' on names imported from a partition.
