[Bug c++/112631] New: gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment

[Bug c++/112631] New: gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment

[michael.kenzel at gmail dot com]

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

            Bug ID: 112631
           Summary: gcc rejects block-scope declaration of function in a
                    module unit even if the function is attached to the
                    global module fragment
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: michael.kenzel at gmail dot com
  Target Milestone: ---

repro: https://godbolt.org/z/h5f798eEY

        export module bla;

        extern "C++" inline void fun()
        {
                void oops();  // error: block-scope extern declaration 'void
oops()' not permitted in module purview
        }

fun is not attached to a named module due to being declared with a linkage
specification (https://eel.is/c++draft/module.unit#7.2). thus,
[dcl.meaning.general]/3.5 (https://eel.is/c++draft/dcl.meaning.general#3.5)
should not apply.

[Bug c++/112631] gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r14-9501-gead3075406ece9daaad65a01ae539150aee43f5a
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date:   Tue Mar 12 23:24:27 2024 +1100

    c++: Check module attachment instead of just purview when necessary
[PR112631]

    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.

            PR c++/112631

    gcc/cp/ChangeLog:

            * cp-tree.h (named_module_attach_p): New function.
            * decl.cc (start_decl): Check for attachment not purview.
            (grokmethod): Likewise.

    gcc/testsuite/ChangeLog:

            * g++.dg/modules/block-decl-1_a.C: New test.
            * g++.dg/modules/block-decl-1_b.C: New test.
            * g++.dg/modules/block-decl-2.C: New test.

    Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

[Bug c++/112631] gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathaniel Shead <nshead@gcc.gnu.org>:

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

commit r14-9530-gc4845edfeaf44756ad9672e8d143f1c8f5c4c0f6
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date:   Sat Mar 16 22:00:29 2024 +1100

    c++: Fix handling of no-linkage decls for modules

    When testing the changes for PR c++/112631 we discovered that currently
    we don't emit definitions of block-scope function declarations if
    they're not used in the module interface TU, which causes issues if they
    are used by importers.

    This patch fixes the handling of no-linkage declarations for C++20. In
    particular, a type declared in a function with vague linkage or declared
    in a module CMI could potentially be accessible outside its defining TU,
    and as such we can't assume that function declarations using that type
    can never be defined in another TU.

    A complication with handling this is that we're only strictly interested
    in declarations with a module CMI, but when parsing the global module
    fragment we don't yet know whether or not this module will have a CMI
    until we reach the "export module" line (or not). Since this case is
    IFNDR anyway (by [basic.def.odr] p11) we just tentatively assume while
    parsing the GMF that this module will have a CMI; once we see (or don't
    see) an 'export module' declaration we can commit to that knowledge for
    future declarations.

    gcc/cp/ChangeLog:

            * cp-tree.h (module_maybe_has_cmi_p): New function.
            * decl.cc (grokfndecl): Mark block-scope functions as public if
            they could be visible in other TUs.
            * decl2.cc (no_linkage_error): Don't error for declarations that
            could be defined in other TUs since C++20. Suppress duplicate
            errors from 'check_global_declaration'.
            * tree.cc (no_linkage_check): In relaxed mode, don't consider
            types in a module CMI to have no linkage.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/linkage-1.C: New test.
            * g++.dg/modules/block-decl-3.h: New test.
            * g++.dg/modules/block-decl-3_a.C: New test.
            * g++.dg/modules/block-decl-3_b.C: New test.
            * g++.dg/modules/block-decl-3_c.C: New test.
            * g++.dg/modules/linkage-1_a.C: New test.
            * g++.dg/modules/linkage-1_b.C: New test.
            * g++.dg/modules/linkage-1_c.C: New test.
            * g++.dg/modules/linkage-2.C: New test.

    Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
    Reviewed-by: Jason Merrill <jason@redhat.com>

[Bug c++/112631] gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment

[nshead at gcc dot gnu.org]

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

Nathaniel Shead <nshead at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |nshead at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |14.0
                 CC|                            |nshead at gcc dot gnu.org

--- Comment #3 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
Fixed for GCC 14.