Enum value name visibility issue with C++20 modules and GMF

[kamrann]

Clang appears to have an issue with visibility of enums included into a module GMF.

// decls.h
enum {
    SomeName,
};

// module.mpp
module;

#include "decls.h"

export module mod;

// consumer.cpp
import mod;

auto a = SomeName;

This compiles without error - I believe incorrectly. Other implementations agree that SomeName is not in scope within consumer.cpp.
Note that Clang agrees with the other implementations under -fmodules-reduced-bmi. Presumably this implies that Clang is making the values visible to name lookup when the enum itself is reachable through the BMI. I couldn't find wording specifically for this case, but it certainly seems wrong intuitively.

See compiler explorer repro.

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: Cameron Angus (kamrann)

Clang appears to have an issue with visibility of enums included into a module GMF.

// decls.h
enum {
    SomeName,
};

// module.mpp
module;

#include "decls.h"

export module mod;

// consumer.cpp
import mod;

auto a = SomeName;

This compiles without error - I believe incorrectly. Other implementations agree that SomeName is not in scope within consumer.cpp.
Note that Clang agrees with the other implementations under -fmodules-reduced-bmi. Presumably this implies that Clang is making the values visible to name lookup when the enum itself is reachable through the BMI. I couldn't find wording specifically for this case, but it certainly seems wrong intuitively.

See compiler explorer repro.

[ChuanqiXu9]

-fmodules-reduced-bmi will be the default option. So I feel this is more or less fine.

[kamrann]

-fmodules-reduced-bmi will be the default option. So I feel this is more or less fine.

I don't think it's technically ok. That flag just happens to hide the issue in the case that the decl gets discarded, but it won't always be discarded. See for example https://godbolt.org/z/q9f4G8Wcs. Here it can't be discarded, but that doesn't mean the name should be visible to lookup in the consumer.

[ChuanqiXu9]

Got it. You're correct here.

[ChuanqiXu9]

I suspect clang's behavior is correct after I look into the spec:

Class and enumeration member names can be found by name lookup in any context in which a definition of the type is reachable.

https://eel.is/c++draft/module.interface#7

With your new example, https://godbolt.org/z/q9f4G8Wcs , the type definition is reachable so it can be found. With the original example, the type definition can be considered as not reachable.

[kamrann]

Hmm, it's interesting. What you linked is technically just a note, suggesting there is somewhere else in the standard that covers the case more formally, but I couldn't find it from a quick search. My gut feeling is that whether or not there is a wording issue, this can't be the intention. That note seems to refer to cases like allowing exported_func().member when the return type of a function is reachable but not exported, which makes sense of course. But I can't believe this is intended for unqualified lookup of namespace scope enums.

For reference, this showed up because I had #include <windows.h> in a GMF, and was getting errors in downstream module units caused by name clashes with various global enums in the windows header. So essentially the exact sort of thing that modules are intended to solve.

[ChuanqiXu9]

Hmm, it's interesting. What you linked is technically just a note, suggesting there is somewhere else in the standard that covers the case more formally, but I couldn't find it from a quick search. My gut feeling is that whether or not there is a wording issue, this can't be the intention. That note seems to refer to cases like allowing exported_func().member when the return type of a function is reachable but not exported, which makes sense of course. But I can't believe this is intended for unqualified lookup of namespace scope enums.

For reference, this showed up because I had #include <windows.h> in a GMF, and was getting errors in downstream module units caused by name clashes with various global enums in the windows header. So essentially the exact sort of thing that modules are intended to solve.

Generally agreed. I've forwarded this to WG21.