Skip to content

Commit ba9c3f0

Browse files
ChuanqiXu9aaryanshukla
authored andcommitted
[docs] [C++20] [Modules] Add a workaround document for missing vtables
Due to llvm#75912 is reverted and llvm#70585 is reopened. It looks riskful to fix the issue correctly before 19. So we provide a workaround here to help people in this trouble as much as possible.
1 parent 5d80f9a commit ba9c3f0

File tree

1 file changed

+68
-0
lines changed

1 file changed

+68
-0
lines changed

clang/docs/StandardCPlusPlusModules.rst

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1092,6 +1092,74 @@ A high-level overview of support for standards features, including modules, can
10921092
be found on the `C++ Feature Status <https://clang.llvm.org/cxx_status.html>`_
10931093
page.
10941094

1095+
Missing VTables for classes attached to modules
1096+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1097+
1098+
Now the compiler may miss emitting the definition of vtables
1099+
for classes attached to modules, if the definition of the class
1100+
doesn't contain any key function in that module units
1101+
(The key function is the first non-pure virtual function that is
1102+
not inline at the point of class definition.)
1103+
1104+
(Note: technically, the key function is not a thing for modules.
1105+
We use the concept here for convinient.)
1106+
1107+
For example,
1108+
1109+
.. code-block:: c++
1110+
1111+
// layer1.cppm
1112+
export module foo:layer1;
1113+
struct Fruit {
1114+
virtual ~Fruit() = default;
1115+
virtual void eval() = 0;
1116+
};
1117+
struct Banana : public Fruit {
1118+
Banana() {}
1119+
void eval() override;
1120+
};
1121+
1122+
// layer2.cppm
1123+
export module foo:layer2;
1124+
import :layer1;
1125+
export void layer2_fun() {
1126+
Banana *b = new Banana();
1127+
b->eval();
1128+
}
1129+
void Banana::eval() {
1130+
}
1131+
1132+
For the above example, we can't find the definition for the vtable of
1133+
class ``Banana`` in any object files.
1134+
1135+
The expected behavior is, for dynamic classes attached to named modules,
1136+
the vtable should always be emitted to the module units the class attaches
1137+
to.
1138+
1139+
To workaround the problem, users can add the key function manually in the
1140+
corresponding module units. e.g.,
1141+
1142+
.. code-block:: c++
1143+
1144+
// layer1.cppm
1145+
export module foo:layer1;
1146+
struct Fruit {
1147+
virtual ~Fruit() = default;
1148+
virtual void eval() = 0;
1149+
};
1150+
struct Banana : public Fruit {
1151+
// Hack a key function to hint the compiler to emit the virtual table.
1152+
virtual void anchor();
1153+
1154+
Banana() {}
1155+
void eval() override;
1156+
};
1157+
1158+
void Banana::anchor() {}
1159+
1160+
This is tracked by
1161+
`#70585 <https://github.com/llvm/llvm-project/issues/70585>`_.
1162+
10951163
Including headers after import is not well-supported
10961164
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10971165

0 commit comments

Comments
 (0)