Skip to content

Commit ded6dd2

Browse files
authored
[clang][NFC] remove resolved issue from StandardCPlusPlusModules.rst (#105610)
This landed as #102287 for main & #102561 for 19.x CC @ChuanqiXu9
1 parent 8039886 commit ded6dd2

File tree

1 file changed

+1
-69
lines changed

1 file changed

+1
-69
lines changed

clang/docs/StandardCPlusPlusModules.rst

Lines changed: 1 addition & 69 deletions
Original file line numberDiff line numberDiff line change
@@ -1297,74 +1297,6 @@ A high-level overview of support for standards features, including modules, can
12971297
be found on the `C++ Feature Status <https://clang.llvm.org/cxx_status.html>`_
12981298
page.
12991299

1300-
Missing VTables for classes attached to modules
1301-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1302-
1303-
Now the compiler may miss emitting the definition of vtables
1304-
for classes attached to modules, if the definition of the class
1305-
doesn't contain any key function in that module units
1306-
(The key function is the first non-pure virtual function that is
1307-
not inline at the point of class definition.)
1308-
1309-
(Note: technically, the key function is not a thing for modules.
1310-
We use the concept here for convinient.)
1311-
1312-
For example,
1313-
1314-
.. code-block:: c++
1315-
1316-
// layer1.cppm
1317-
export module foo:layer1;
1318-
struct Fruit {
1319-
virtual ~Fruit() = default;
1320-
virtual void eval() = 0;
1321-
};
1322-
struct Banana : public Fruit {
1323-
Banana() {}
1324-
void eval() override;
1325-
};
1326-
1327-
// layer2.cppm
1328-
export module foo:layer2;
1329-
import :layer1;
1330-
export void layer2_fun() {
1331-
Banana *b = new Banana();
1332-
b->eval();
1333-
}
1334-
void Banana::eval() {
1335-
}
1336-
1337-
For the above example, we can't find the definition for the vtable of
1338-
class ``Banana`` in any object files.
1339-
1340-
The expected behavior is, for dynamic classes attached to named modules,
1341-
the vtable should always be emitted to the module units the class attaches
1342-
to.
1343-
1344-
To workaround the problem, users can add the key function manually in the
1345-
corresponding module units. e.g.,
1346-
1347-
.. code-block:: c++
1348-
1349-
// layer1.cppm
1350-
export module foo:layer1;
1351-
struct Fruit {
1352-
virtual ~Fruit() = default;
1353-
virtual void eval() = 0;
1354-
};
1355-
struct Banana : public Fruit {
1356-
// Hack a key function to hint the compiler to emit the virtual table.
1357-
virtual void anchor();
1358-
1359-
Banana() {}
1360-
void eval() override;
1361-
};
1362-
1363-
void Banana::anchor() {}
1364-
1365-
This is tracked by
1366-
`#70585 <https://github.com/llvm/llvm-project/issues/70585>`_.
1367-
13681300
Including headers after import is not well-supported
13691301
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13701302

@@ -1436,7 +1368,7 @@ non-module unit depending on the definition of some macros. However, this usage
14361368
is forbidden by P1857R3 which is not yet implemented in Clang. This means that
14371369
is possible to write invalid modules which will no longer be accepted once
14381370
P1857R3 is implemented. This is tracked by
1439-
`#56917 <https://github.com/llvm/llvm-project/issues/56917>`_.
1371+
`#54047 <https://github.com/llvm/llvm-project/issues/54047>`_.
14401372

14411373
Until then, it is recommended not to mix macros with module declarations.
14421374

0 commit comments

Comments
 (0)