On Thu, Nov 23, 2023 at 03:03:37PM -0500, Nathan Sidwell wrote:
> On 11/20/23 04:47, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
> > access.
> >
> > -- >8 --
> >
> > Block-scope declarations of functions or extern values are not allowed
> > when attached to a named module. Similarly, class member functions are
> > not inline if attached to a named module. However, in both these cases
> > we currently only check if the declaration is within the module purview;
> > it is possible for such a declaration to occur within the module purview
> > but not be attached to a named module (e.g. in an 'extern "C++"' block).
> > This patch makes the required adjustments.
>
>
> Ah I'd been puzzling over the default inlinedness of member-fns of
> block-scope structs. Could you augment the testcase to make sure that's
> right too?
>
> Something like:
>
> // dg-module-do link
> export module Mod;
>
> export auto Get () {
> struct X { void Fn () {} };
> return X();
> }
>
>
> ///
> import Mod
> void Frob () { Get().Fn(); }
>
I gave this a try and it indeed doesn't work correctly; 'Fn' needs to be
marked 'inline' for this to link (whether or not 'Get' itself is
inline). I've tried tracing the code to work out what's going on but
I've been struggling to work out how all the different flags (e.g.
TREE_PUBLIC, TREE_EXTERNAL, TREE_COMDAT, DECL_NOT_REALLY_EXTERN)
interact, which flags we want to be set where, and where the decision of
what function definitions to emit is actually made.
I did find that doing 'mark_used(decl)' on all member functions in
block-scope structs seems to work however, but I wonder if that's maybe
too aggressive or if there's something else we should be doing?
