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

    <tr>
        <th>Summary</th>
        <td>
            [C++20] [Modules] We didn't implement lookup in module level actually
        </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>
    Minimal reproducer:

```
// a.cppm
export module a;
namespace a { int a = 43; }

// use.cc
import a;
namespace a {
    double a = 43.0
}
```

We should accept the example since the `a::a` in module a is not visible from `use.cc` and also the `a::a` in module a is a different entity with `a::a` in use.cc so they don't violate the ODR rule. 

The root reason is that how do we handle the module's visibility in clang. Now in clang, the process to judge the visibility of declarations is:

```
lookup  a name -> lookup the name in **all** imported modules -> judge if all the found declarations are valid (ODR Check, etc...) -> check the visibility of found declarations
```

Then the reason about the failure is clear. We check the visibility after we check the validness of found declarations. Then it booms out in the checking validness phase. So the visibility doesn't get involved here.

The reason why we implement it as this is that:
- We can only get the visibility of a declaration after deserializing it. So we must check the visibility after deserializing it.
- If we deserialize something, we'd better to check its validness immediately. Otherwise we may be in unsafe state.

To solve the first problem, we need to be able to get the module file of a declaration before deserializing it. This requires us to change the encodings of serialized declaration ID. See https://github.com/llvm/llvm-project/pull/86912 for example.

For the second problem, maybe we have to refactor the current design of declarations to make `a::a@a` to be a well-defined different  entity with `a::a` in the global module.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUVk2P2zYQ_TX0ZbCCTPkjPviwXtdADmmAJkB6HZEjiwlFKvyw4_76gqTW6423aQssvPZIfDPvzZuR0Ht1NERbttyx5X6GMfTWbZ_6iOa7-jNuZq2Vl-0HZdSAGhyNzsooyLHmkdV7Vj9_rurpr_zkB8YPgJUYx6GE6MdoXYDByqgJkDW7Ejc4kB9RECCw9Q6UCelbs4dFw5odsPX-VaKCHD1VQpSQGjLyP0KWIACAtLHVdIWvnqu9pviJRf78QuB7G7UEFILGAKEnoB84jJrAKyMoR9iqxiRK84hsVYMyV6qgPBgb4KS8Suk7Z4d0-8RhVQMaCai9_Q9ACFJ1HTkyAcgEFS5wVqF_41SBh4J6AWkN4-tUhdUYSs0f93-Ai5oquCX8uSdw1gZwhN6alDX0GKC3Z5AWzgQ9GqkLRKmN8bUv_JROJSkDQqM5VvC7PV9_Mf6Uz4zOCvIegoWvUR4L0M1p24EkodFhUNZ4UP7XbtPWfosjAELqPDyw5jeYYgk5B5UBxh8Zf0StyxcoviE5cfDlYKlIdYBa5-OdjUa-LggdwQm1ksD4uyTiU0_iW6JHQVRVxfimgIkUf4PePeYvDPi5J5Mxpn5ga2NxYYdKR0epQ0ITugq-0Ns5sQvkUuturiYCJvXhzYIqyHlVgNbawUPKqUodGUOZ4w3E2KOnCj7ZnxNLS74Y70gJ4GT1iST05Ki6M13hd-4vqVKVBmxIPlcBMHlQ-WcvXv3wkBmjAWv0Jae4FxtveU1KSPLkFGr1V-KhQi79TDBEH36l4N255zLed-n4y2UCbwcKvSq2P6cRkdBSSCjBTjlU8DciqmEgqTCQvlTwMfTkzspTLgsv0GYTR-OxI_ABw08CWvBJ22IM5XxIc9ZqGkp-MEQyZW4JMK2hYK96TQumU5ruBWups47eUOxzaoij71E58hB9oYVmGmgywkpljtlfV1lemQze7yv4RAR9CGMe8rzdjyr0sa2EHRg_aH16_vcwOvuVRGD8MMY0xod3q82cQ2fd80J-JcnBulyJJ2GNvJVjwEtLZZOdshKOOhRhul9El_erpPRwvFtHwcKA314v6kWd1-4kL5xJ6wdJnTKJ8HVh_8vGTrmP2raop45UM7lt5KbZ4Iy28_V8UW_Wm2Y167ebrm2wxhZx0YgFyY2U8-W6Wy2XEjvB5zO15TVf1Au-qvn83XJVNbyTtNms67WQiwVPJdOASldJ2cq640x5H2m7qefLxUxjS9rntwLOy_JuHqc9yThPrwpum3vSxqNni1orH_wLVlBB55eKJ8Z3jO94zZZ7YMvdhwljuU-TK5Usy-Fl2KfF_fLY03QiDShCRK0vs-j09n_bJVPzjB8yu78DAAD__2uc75Q">