On 8/24/25 9:04 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
On looking again at [basic.lookup.argdep] p4, I believe GCC hasn't fully
implemented the wording here for ADL. This patch fixes two issues.
First, 4.3 indicates that a function exported from a named module should
be visible to ADL regardless of whether it's visible to normal name
lookup, as long as some restrictions are followed.
This patch implements this, except I'm not 100% sure what the impact of
skipping declarations that "do not appear in the TU containing the point
of lookup" is meant to result in, except maybe that we're not supposed
to consider exported functions later on in the current TU? So I don't
think there's anything to do there.
I guess it means that 'assocs' should not include module 0.
Secondly, currently we only add the exported functions along the
instantiation path of a lookup. But I don't think this is intended by
the current wording, so this patch adjusts that. I also clean up the
logic to do all different module processing in adl_namespace_fns so that
we don't duplicate work in traversing the module binding list
unnecessarily.
This new handling means we need to do some extra work to properly error
on overload sets containing TU-local entities (as this might actually
come up now!) but I'm leaving that for a later patch.
As a drive-by fix this also fixes an ICE for C++26 expansion statements
with finding the instantiation path.
@@ -20832,8 +20832,9 @@ path_of_instantiation (tinst_level *tinst, bitmap
*path_map_p)
{
gcc_checking_assert (modules_p ());
- if (!tinst)
+ if (!tinst || TREE_CODE (tinst->tldcl) == TEMPLATE_FOR_STMT)
Hmm, this seems wrong; I'd expect that expanding an expansion statement
can appear in the middle of a chain of instantiations, so we don't want
to stop recursing.
{
+ gcc_assert (!tinst || !tinst->next);
/* Not inside an instantiation, just the regular case. */
*path_map_p = nullptr;
return get_import_bitmap ();
@@ -1294,10 +1303,26 @@ name_lookup::adl_namespace_fns (tree scope, bitmap
imports)
dup_detect |= dup;
}
- bind = STAT_VISIBLE (bind);
+ /* For lookups on the instantiation path we can see any
+ module-linkage declaration; otherwise we should only
+ see exported decls. */
+ if (!on_inst_path)
+ bind = STAT_VISIBLE (bind);
}
- add_fns (bind);
+ if (on_inst_path || visible)
+ add_fns (bind);
+ else
+ {
+ /* We're only accessible because we're the same module as
+ an associated entity with module attachment: only add
+ functions actually attached to this module. */
+ for (tree fn : ovl_range (bind))
+ if (DECL_DECLARES_FUNCTION_P (fn)
+ && DECL_LANG_SPECIFIC (STRIP_TEMPLATE (fn))
+ && DECL_MODULE_ATTACH_P (STRIP_TEMPLATE (fn)))
Do we not need to check which module it's attached to? That is, can we
get here for a re-exported import?
+ add_overload (fn);
Jason
