Seemingly incorrect treatment of constexpr member functions in modules #107673
Comments
EugeneZelenko
added
clang:modules
|
@llvm/issue-subscribers-clang-modules Author: Cameron Angus (kamrann)
According to the standard, member functions defined within a class definition are implicitly `inline` in the global module, but not so within a module purview. However, the standard also states that `constexpr` member functions are implicitly inline, and in this case makes no exception for modules.
[11.4.2/1 [class.mfct] - see also Note 1](https://eel.is/c++draft/class.mfct#1) As such all I believe the difference between clang and gcc seen here is fundamentally the cause. Clang is generating code for a function marked |
|
Latest now behaving as I expected. Thank you! |
|
Given 19.x is released and both the fixes are simple. I'd like to try to back them. |
|
/cherry-pick 74ac96a |
…itly inline Close llvm#107673 (cherry picked from commit 74ac96a)
|
/pull-request #109076 |
…itly inline Close llvm#107673 (cherry picked from commit 74ac96a)
According to the standard, member functions defined within a class definition are implicitly
inlinein the global module, but not so within a module purview. However, the standard also states thatconstexprmember functions are implicitly inline, and in this case makes no exception for modules.11.4.2/1 [class.mfct] - see also Note 1
9.2.6/1 [dcl.constexpr]
As such all
constexprmember functions should beinline, regardless of modules. From what I can see, clang is not respecting this. I'm seeing linker errors for such member functions when using modules with shared libraries.I believe the difference between clang and gcc seen here is fundamentally the cause. Clang is generating code for a function marked
constexprbut not for one markedinline constexpr, yet if I'm interpreting the standard correctly these cases should be equivalent.The text was updated successfully, but these errors were encountered: