On 9/23/24 7:46 PM, Nathaniel Shead wrote:
Currently I just stream DECL_NAME in TU_LOCAL_ENTITYs for use in diagnostics,
but this feels perhaps insufficient. Are there any better approached here?
Otherwise I don't think it matters too much, as which entity it is will also
be hopefully clear from the 'declared here' notes.
I've put the new warning in Wextra, but maybe it would be better to just
leave it out of any of the normal warning groups since there's currently
no good way to work around the warnings it produces?
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
[basic.link] p14 lists a number of circumstances where a declaration
naming a TU-local entity is not an exposure, notably the bodies of
non-inline templates and friend declarations in classes. This patch
ensures that these references do not error when exporting the module.
We do need to still error on instantiation from a different module,
however, in case this refers to a TU-local entity. As such this patch
adds a new tree TU_LOCAL_ENTITY which is used purely as a placeholder to
poison any attempted template instantiations that refer to it.
This is also streamed for friend decls so that merging (based on the
index of an entity into the friend decl list) doesn't break and to
prevent complicating the logic; I imagine this shouldn't ever come up
though.
We also add a new warning, '-Wignored-exposures', to handle the case
where someone accidentally refers to a TU-local value from within a
non-inline function template. This will compile without errors as-is,
but any attempt to instantiate the decl will fail; this warning can be
used to ensure that this doesn't happen. Unfortunately the warning has
quite some false positives; for instance, a user could deliberately only
call explicit instantiations of the decl, or use 'if constexpr' to avoid
instantiating the TU-local entity from other TUs, neither of which are
currently detected.
I disagree with the term "ignored exposure", in the warning name and in
the rest of the patch; these references are not exposures. It's the
naming of a TU-local entity that is ignored in basic.link/14.
I like the warning, just would change the name.
"-Wtemplate-names-tu-local"? "-Wtu-local-in-template"?
I'm not too concerned about false positives, as long as it can be
effectively suppressed with #pragma GCC diagnostic ignored. If you only
use explicit instantiations you don't need to have the template body in
the interface anyway.
+ /* Ideally we would only warn in cases where there are no explicit
+ instantiations of the template, but we don't currently track this
+ in an easy-to-find way. */
You can't walk DECL_TEMPLATE_INSTANTIATIONS checking
DECL_EXPLICIT_INSTANTIATION?
What happens with a non-templated, non-inline function body that names a
TU-local entity? I don't see any specific handling or testcase. Should
we just omit its definition, like you do in the previous patch for
TU-local variable initializers?
Jason
