<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/102290>102290</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [C++20] [Modules] Review the design of DeclContext and Owning Modules
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang:modules
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          ChuanqiXu9
      </td>
    </tr>
</table>

<pre>
    (From the discussion in https://github.com/llvm/llvm-project/pull/102115)

# Status quo

Currently, the owning module of a declaration will be set when created in:
https://github.com/llvm/llvm-project/blob/47bf996abe4fafa8192c78c472d68c6519349e90/clang/lib/AST/DeclBase.cpp#L106-L108

But the TU doesn't have a parent context, so it doesn't have owning module at first. Also to ease the process of assigning modules, we will assign the global module fragment, the current named module and the private module fragment as the owning module for the TU: https://github.com/llvm/llvm-project/blob/9dae7fcc927de7ae9878d4c32cb15770271fa8e3/clang/lib/Sema/SemaModule.cpp#L178 , https://github.com/llvm/llvm-project/blob/9dae7fcc927de7ae9878d4c32cb15770271fa8e3/clang/lib/Sema/SemaModule.cpp#L472, https://github.com/llvm/llvm-project/blob/9dae7fcc927de7ae9878d4c32cb15770271fa8e3/clang/lib/Sema/SemaModule.cpp#L568
 . Then when we create a new declaration in the GMF or the module purview, we will assign the correct module linkage for the new declaration.

It looks like the root of the problem to change the owning module for the TU decl. But I want to note that the current mechanism works well actually for a long time.

#  Possible solutions

I think, the most appropriate solution is to create more decl contexts and not touch the TU decl. For example, when we see a `module;` declaration, we should create and push a GlobalModuleFragmentDecl (which is also DeclContext) to the current decl context stack. Similarly, when we see the module declaration, we should create and push a ModuleDecl. Then we may solve the problem more naturally.

# Related Questions

Then it is an interesting question that, whether or not should the TU be attached to a module? From the specification, the translation units are classified into module units and non-module unit. So maybe it looks better to introduce ModuleUnitDecl as derived class for the TransaltionUnitDecl. Is it?
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzMVk1v2zgT_jX0ZVBDoiRLOvgQJ1BRoMX7bpMCex1RI4sbilRJym7-_YKUnDjJ7gK59ZIAMjl8PuYZEp2TR020Z8WBFXcbnP1g7P52mFH_lH_O9aY13dOe8aqxZgQ_EHTSidk5aTRIDYP3k2PZDeMN481R-mFut8KMjDdKnS7_Pk3W_EXCM95Ms1KMN2nC07RgvGbJHUtu1r88g3uPfnbwczbXv9zO1pL26onx24jCnLXURxhNNysC0wNCR0KhRR-QnaVS0BI48nAeSIOwhJ46kDqAjTU_DL1VpmW8ycu2r-sdtpT32GOV1lyUlchL3u0qsSvSOstrqhPGG6FQH0MhGTbe3D8w3tyRUAd0tBXTxHj2NU12n76mSXVN9zD7yPLhB3SGnGa89DDgiQBhwqAECKM9_fJBD2dA-rcLXwuEHnppnd_CjXIGvAFCR_GMyRpBzkUNYze8bHOh-pkWNZcf45ajMi2qS-3e4nEk7S_WiMUr0DhS9wxAd-tp8oSe3u4FdP9ga2_sKgPLbj7eaqtfdYdU9kLUvOyoRKqrsupykXHRpkVZJrxMe6woe-fXPY24_vsWAT1bVlYQ2P4-iPKS_16Ait3a0LCFhxDAmMIzrUEEBE3nV5GVS299_tbAavvaBdNsT5LO_9KLwlhLwl8WK6kf8fjSOm9O2V6n7IsHZcyjAyUflyxYY3wIwpqLVtEYsiIG1Ef6zwaNh2whBPcLnFH7sE8bH3ahf5WLkUI96UY4G_vo4EyBkfAzKvUUSyIoo4_g5Ujbt_MR_m-ck60icEbNgZN7xQn8IPXjJYujcR5wmqyZrAy6XzaBdJHZ4sZoLEUGl7HiYmC1CTRmMbwm2RgL9AvHSVE0ZXXWUbCV7ZJFHJYd2C65Fn910A1mVt1zI-gOptkNgPA5jpWlj5p1MIRpCYxX50GKIYDGML_C19vLAKwDkWuBr4mA8yget3AvR6nQLhfINeKrRvsA1AXkXZTjYa024lOQ90Sv2idKq9HPNtj7zs7vpOK99MdM7p2ZsbL0kXYIiCcbVukj_FyXx-5aKfmBbIhOcG0FvtrWhgvAoxioC1ohXBxq4PladxMJ2UvxTD989Ba1U0s-Zy1DW1gCoUL-ehmvU28u8q0LYt_oT1cft3BvgjotBTJL5FrynmxAI7W3ppsFraL-0HJxHR10ZOWJuuXEl7QFVKgCqsviLXxxID3Lmk23z7o6q3FD-7TkWcLTqk42w75IkfK846Io-Y4nu12-y7s8LcSuLZOkLjZyzxOeJ1VSJnWaZsk2JVH3HfXUlnmVZh3LExpRqm0Yoltjjxvp3Ez7NOG8TjYKW1IuvqQ4X8ZkdvN8kfLwvLL7OH_b-ehYnijpvHsp5qVX8SF2y_iB8QNPWHEHrDh8W2sUd_Cdwihc3mEUZ6Dpr9MQ5f_fMqPWbZvZqv2HL4bIzC0PtUDutOd_BwAA__8hpGa-">