* [Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer
2024-04-10 20:22 [Bug c++/114683] New: [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer m.cencora at gmail dot com
@ 2024-05-24 14:36 ` nshead at gcc dot gnu.org
2024-06-12 21:14 ` jason at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: nshead at gcc dot gnu.org @ 2024-05-24 14:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Nathaniel Shead <nshead at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-05-24
CC| |nshead at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
Confirmed. Another related testcase with a different kind of using-declaration
from PR114868:
// using_enum_a.cpp
module;
namespace foo {
enum class a { x, y, z };
}
export module M:a;
namespace bar {
export using enum foo::a;
}
// using_enum_b.cpp
export module M;
export import :a;
// using_enum_c.cpp
import M;
int main() {
auto x = bar::x;
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer
2024-04-10 20:22 [Bug c++/114683] New: [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer m.cencora at gmail dot com
2024-05-24 14:36 ` [Bug c++/114683] " nshead at gcc dot gnu.org
@ 2024-06-12 21:14 ` jason at gcc dot gnu.org
2024-06-13 15:06 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: jason at gcc dot gnu.org @ 2024-06-12 21:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
CC| |jason at gcc dot gnu.org
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer
2024-04-10 20:22 [Bug c++/114683] New: [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer m.cencora at gmail dot com
2024-05-24 14:36 ` [Bug c++/114683] " nshead at gcc dot gnu.org
2024-06-12 21:14 ` jason at gcc dot gnu.org
@ 2024-06-13 15:06 ` cvs-commit at gcc dot gnu.org
2024-06-13 15:09 ` jason at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-06-13 15:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>:
https://gcc.gnu.org/g:609764a42f0cd3f6358562cab98fc220d3d2d9fd
commit r15-1297-g609764a42f0cd3f6358562cab98fc220d3d2d9fd
Author: Jason Merrill <jason@redhat.com>
Date: Wed Jun 12 18:24:35 2024 -0400
c++/modules: export using across namespace [PR114683]
Currently we represent a non-function using-declaration by inserting the
named declaration into the target scope. In general this works fine, but
in
the case of an exported using-declaration we have nowhere to mark the
using-declaration as exported, so we mark the original declaration as
exported instead, and then treat all using-declarations that name it as
exported as well. We were doing this only if there was also a previous
non-exported using, so for this testcase the export got lost; this patch
broadens the workaround to also apply to the using that first brings the
declaration into the current scope.
This does not fully resolve 114683, but replaces a missing exports bug with
an extra exports bug, which should be a significant usability improvement.
The testcase has xfails for extra exports.
I imagine a complete fix should involve inserting a USING_DECL.
PR c++/114683
gcc/cp/ChangeLog:
* name-lookup.cc (do_nonmember_using_decl): Allow exporting
a newly inserted decl.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-22_a.C: New test.
* g++.dg/modules/using-22_b.C: New test.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer
2024-04-10 20:22 [Bug c++/114683] New: [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer m.cencora at gmail dot com
` (2 preceding siblings ...)
2024-06-13 15:06 ` cvs-commit at gcc dot gnu.org
@ 2024-06-13 15:09 ` jason at gcc dot gnu.org
2024-06-23 7:26 ` nshead at gcc dot gnu.org
2024-07-12 12:58 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: jason at gcc dot gnu.org @ 2024-06-13 15:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org
--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed the missing export in favor of extra wrong exports. I'm leaving this
open for that bug, and am no longer working on it; I hope my workarounds don't
interfere with any work Nathaniel is pursuing.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer
2024-04-10 20:22 [Bug c++/114683] New: [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer m.cencora at gmail dot com
` (3 preceding siblings ...)
2024-06-13 15:09 ` jason at gcc dot gnu.org
@ 2024-06-23 7:26 ` nshead at gcc dot gnu.org
2024-07-12 12:58 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: nshead at gcc dot gnu.org @ 2024-06-23 7:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Nathaniel Shead <nshead at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer
2024-04-10 20:22 [Bug c++/114683] New: [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer m.cencora at gmail dot com
` (4 preceding siblings ...)
2024-06-23 7:26 ` nshead at gcc dot gnu.org
@ 2024-07-12 12:58 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-07-12 12:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
--- Comment #4 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:d6bf4b1c93221118b3008a878ec508f6412dfc55
commit r15-2003-gd6bf4b1c93221118b3008a878ec508f6412dfc55
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date: Thu Jun 27 11:08:15 2024 +1000
c++: Introduce USING_DECLs for non-function usings [PR114683]
With modules, a non-function using-declaration is not completely
interchangable with the declaration that it refers to; in particular,
such a using-declaration may be exported without revealing the name of
the entity it refers to.
This patch fixes this by building USING_DECLs for all using-declarations
that bind a non-function from a different scope. These new decls can
than have purviewness and exportingness attached to them without
affecting the decl that they refer to.
We do this for all such usings, not just usings that may be revealed in
a module; this way we can verify the change in representation against
the (more comprehensive) non-modules testsuites, and in a future patch
we can use the locations of these using-decls to enhance relevant
diagnostics.
Another possible approach would be to reuse OVERLOADs for this, as is
already done within add_binding_entity for modules. I didn't do this
because lots of code (as well as the names of the accessors) makes
assumptions that OVERLOADs refer to function overload sets, and so
splitting this up reduced semantic burden and made it easier to avoid
unintentional changes. This did mean that we need to move out the
definitions of ovl_iterator::{purview,exporting}_p, because the
structures for module decls are declared later on in cp-tree.h.
Building USING_DECLs changed a couple of code paths when adjusting
bindings; in particular, pushdecl recognises global using-declarations
as usings now, and so checks fall through to update_binding. To not
regress g++.dg/lookup/linkage2.C the checks for 'extern' declarations no
longer were sufficient (they don't handle 'extern "C"'); but
duplicate_decls performed all the relevant checks anyway.
Otherwise in general we strip using-decls from all lookup_* functions
where necessary. Over time for diagnostics purposes it would probably
be good to slowly revert this (especially e.g. lookup_elaborated_type
causes some diagnostic quality regressions here) but this patch doesn't
do so to minimise churn.
This patch also tries not to build USING_DECLs when just redeclaring an
existing declaration, and instead reveals that declaration in-place.
This requires reworking some logic handling CONST_DECLs in module
streaming, since a non-using CONST_DECL may now be exported indepenently
of its containing enum.
'add_binding_entity' needs to explicitly write the names of unscoped
enumerators so that lazy loading will trigger when the name is found by
name lookup; it does this by pretending that the enum declarations are
always usings so that it doesn't double-write definitions. By also
checking if the enumerator was marked purview/exported we can use that
to override a non-purview/non-exported TYPE_DECL and ensure it's made
visible regardless.
When reading we should get the exported flag on the enumeration
constant, and so should properly create a binding for it. We don't need
to do anything to handle importedness as that checking is skipped for
EK_USINGs.
Some other places assume that module information for a CONST_DECL
inherits module information from its containing type. This includes:
- get_originating_module_decl, for determining if the name was imported
or has module attachment; I don't /think/ this change should affect
that, so I'm leaving this untouched.
- binding_cmp, for sorting by exportedness; since now an enumerator
could be exported without the containing decl being exported, we need
to handle this here too.
PR c++/114683
gcc/cp/ChangeLog:
* cp-tree.h (class ovl_iterator): Move definitions of purview_p
and exporting_p to name-lookup.cc.
* module.cc (depset::hash::add_binding_entity): Strip
using-decls. Remove workarounds. Handle CONST_DECLs with
different purview/exported from their enum.
(enum ct_bind_flags): Remove unnecessary cbf_wrapped flag.
(module_state::write_cluster): Likewise.
(module_state::read_cluster): Build USING_DECL for non-function
usings.
(binding_cmp): Handle CONST_DECLs with different purview and/or
exported from their enum.
(set_instantiating_module): Support CONST_DECLs.
* name-lookup.cc (get_fixed_binding_slot): Strip USING_DECLs.
(name_lookup::process_binding): Strip USING_DECLs.
(name_lookup::process_module_binding): Remove workaround.
(update_binding): Strip USING_DECLs, remove incorrect check for
non-extern variables.
(ovl_iterator::purview_p): Support USING_DECLs.
(ovl_iterator::exporting_p): Support USING_DECLs.
(walk_module_binding): Handle stat hack type.
(do_nonmember_using_decl): Strip USING_DECLs when comparing;
build USING_DECLs for non-function usings in different scope
rather than binding directly.
(get_namespace_binding): Strip USING_DECLs.
(lookup_name): Strip USING_DECLs.
(lookup_elaborated_type): Strip USING_DECLs.
* decl.cc (poplevel): Still support -Wunused for using-decls.
(lookup_and_check_tag): Remove unnecessary strip_using_decl.
* parser.cc (cp_parser_template_name): Likewise.
(cp_parser_nonclass_name): Likewise.
(cp_parser_class_name): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/lookup/using29.C: Update errors.
* g++.dg/lookup/using53.C: Update errors, add XFAILs.
* g++.dg/modules/using-22_b.C: Remove xfails.
* g++.dg/warn/Wunused-var-18.C: Update error, add check.
* g++.dg/lookup/using68.C: New test.
* g++.dg/modules/using-24_a.C: New test.
* g++.dg/modules/using-24_b.C: New test.
* g++.dg/modules/using-25_a.C: New test.
* g++.dg/modules/using-25_b.C: New test.
* g++.dg/modules/using-enum-4_a.C: New test.
* g++.dg/modules/using-enum-4_b.C: New test.
* g++.dg/modules/using-enum-4_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
^ permalink raw reply [flat|nested] 7+ messages in thread