On 5/31/24 11:57, Nathaniel Shead wrote:
On Tue, May 28, 2024 at 02:57:09PM -0400, Jason Merrill wrote:
What if we're revealing without exporting? That is, a using-declaration in
module purview that isn't exported? Such a declaration should still prevent
discarding, which is my understanding of the use of "revealing" here.
It seems like the current code already gets that wrong for e.g.
M_1.C:
module;
struct A {};
inline int f() { return 42; }
export module M;
using ::A;
using ::f;
M_2.C:
import M;
inline int f();
struct A a; // { dg-bogus "incomplete" }
int main() {
return f(); // { dg-bogus "undefined" }
}
It looks like part of the problem is that add_binding_entity is only
interested in exported usings, but I think it should also handle revealing
ones.
Right; I hadn't thought about that. The cleanest way to solve this I
think is to add a new flag to OVERLOAD to indicate their purviewness,
which we can then use in 'add_binding_entity' instead of the current
reliance on exported usings; this is what I've done in the below patch.
(There aren't any more TREE_LANG_FLAG_?s left so I just picked another
unused flag lying around; alternatively I could create _7, there does
seem to be spare bits in tree_base.)
Another option would be to do like what I've done in my workaround for
non-functions and just mark the original decl as being in PURVIEW_P; I'm
not a huge fan of this though.
Agreed.
+ /* FIXME: Handle exporting declarations from a different scope
+ without also marking those declarations as exported.
+ This will require not just binding directly to the underlying
+ value; see c++/114863 and c++/114865. We allow this for purview
+ declarations for now as this doesn't (currently) cause ICEs
+ later down the line, but should also be revisited then. */
I'm not sure what "then" you're referring to?
OK either clarifying, or striking "also" and "then".
Jason
