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

[via cfe-commits]

Author: h-vetinari
Date: 2024-08-22T13:32:40+08:00
New Revision: ded6dd244cce3e683201a668ce321d4474baa8fb

URL: https://github.com/llvm/llvm-project/commit/ded6dd244cce3e683201a668ce321d4474baa8fb
DIFF: https://github.com/llvm/llvm-project/commit/ded6dd244cce3e683201a668ce321d4474baa8fb.diff

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

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

Added: 
    

Modified: 
    clang/docs/StandardCPlusPlusModules.rst

Removed: 
    


################################################################################
diff  --git a/clang/docs/StandardCPlusPlusModules.rst b/clang/docs/StandardCPlusPlusModules.rst
index ccc0cb59f8e710..1469feb3ad45bd 100644
--- a/clang/docs/StandardCPlusPlusModules.rst
+++ b/clang/docs/StandardCPlusPlusModules.rst
@@ -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.