[clang][NFC] remove resolved issue from StandardCPlusPlusModules.rst (l…

…lvm#105610)

This landed as llvm#102287 for main
& llvm#102561 for 19.x

CC @ChuanqiXu9

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.