caio/clang-p2996
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[clang][NFC] remove resolved issue from StandardCPlusPlusModules.rst (#105610)

Browse Source 
This landed as https://github.com/llvm/llvm-project/pull/102287 for main
& https://github.com/llvm/llvm-project/pull/102561 for 19.x

CC @ChuanqiXu9
This commit is contained in:
h-vetinari
2024-08-22 16:32:40 +11:00
committed by GitHub
parent 8039886e6d
commit ded6dd244c
1 changed files with 1 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
clang/docs/StandardCPlusPlusModules.rst
View File

@@ -1297,74 +1297,6 @@ A high-level overview of support for standards features, including modules, can
be found on the `C++ Feature Status <https://clang.llvm.org/cxx_status.html>`_
page.
Missing VTables for classes attached to modules
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now the compiler may miss emitting the definition of vtables
for classes attached to modules, if the definition of the class
doesn't contain any key function in that module units
(The key function is the first non-pure virtual function that is
not inline at the point of class definition.)
(Note: technically, the key function is not a thing for modules.
We use the concept here for convinient.)
For example,
.. code-block:: c++
// layer1.cppm
export module foo:layer1;
struct Fruit {
virtual ~Fruit() = default;
virtual void eval() = 0;
};
struct Banana : public Fruit {
Banana() {}
void eval() override;
};
// layer2.cppm
export module foo:layer2;
import :layer1;
export void layer2_fun() {
Banana *b = new Banana();
b->eval();
}
void Banana::eval() {
}
For the above example, we can't find the definition for the vtable of
class ``Banana`` in any object files.
The expected behavior is, for dynamic classes attached to named modules,
the vtable should always be emitted to the module units the class attaches
to.
To workaround the problem, users can add the key function manually in the
corresponding module units. e.g.,
.. code-block:: c++
// layer1.cppm
export module foo:layer1;
struct Fruit {
virtual ~Fruit() = default;
virtual void eval() = 0;
};
struct Banana : public Fruit {
// Hack a key function to hint the compiler to emit the virtual table.
virtual void anchor();
Banana() {}
void eval() override;
};
void Banana::anchor() {}
This is tracked by
`#70585 <https://github.com/llvm/llvm-project/issues/70585>`_.
Including headers after import is not well-supported
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1436,7 +1368,7 @@ non-module unit depending on the definition of some macros. However, this usage
is forbidden by P1857R3 which is not yet implemented in Clang. This means that
is possible to write invalid modules which will no longer be accepted once
P1857R3 is implemented. This is tracked by
`#56917 <https://github.com/llvm/llvm-project/issues/56917>`_.
`#54047 <https://github.com/llvm/llvm-project/issues/54047>`_.
Until then, it is recommended not to mix macros with module declarations.