Incorrect member inaccessible error in friend class/function when class is in separate C++ 20 module

Bug type: Language Service

Describe the bug

• OS and Version: Windows 11 x64 22000.318
• VS Code Version: 1.62.3
• C/C++ Extension Version: v1.7.1
• MSVC Version: 14.30.30705, x64 (in VS 2022)
• Other extensions you installed (and if the issue persists after disabling them):
  • Was using the Meson extension and various others, however the issue exists with all other extensions disabled.

When using C++20 modules, the language server gives a false positive member inaccessible error when using a friend class or friend function to access a private member of a class if the class is in another C++20 module.

Using a single project, single folder workspace (not tested on others but probably will have the same result)

#6302 is relevant to this issue, but separate. Module import IntelliSense is not required for the extension to detect imported types from other modules (via IFC files).

Steps to reproduce

1. Create a new workspace directory with the code samples and C/C++ configuration below.

   • The important part is to have a class in one module m, and have a friend class or friend function of that class in another module that imports m and accesses a private member of an instance of that class.

2. Compile m.cpp (just to have the IFC file)

   cl.exe /c /std:c++20 /experimental:module /interface m.cpp
   

3. Observe the following:

   • IntelliSense correctly does not produce errors for the C++20 module syntax and correctly identifies the class Test (can be verified with Go to Definition)
   • However, the use of t.privateMember does produce an error, even though the code compiles fine:

     member "Test::privateMember" (declared at line 5 of module "m" ("<...>\m.cpp")) is inaccessible
     

Expected behavior
This error is a false-positive. The code for both files compiles and links fine. Accessing the private member should work because int main() is a friend function of class Test.

Code sample and logs

• Code sample

  m.cpp:

  export module m;
  
  export class Test {
  private:
      int privateMember;
      friend int main();
  };
  

  u.cpp:

  import m;
  
  int main()
  {
    Test t;
    t.privateMember = 0;
    return 0;
  }
  

• Configurations in c_cpp_properties.json

  .vscode/c_cpp_properties.json:

  {
      "configurations": [
          {
              "name": "Win32",
              "includePath": [
                  "${workspaceFolder}/**"
              ],
              "defines": [
                  "_DEBUG",
                  "UNICODE",
                  "_UNICODE"
              ],
              "windowsSdkVersion": "10.0.19041.0",
              "compilerPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.30.30705\\bin\\Hostx64\\x64\\cl.exe",
              "cStandard": "c17",
              "cppStandard": "c++20",
              "intelliSenseMode": "windows-msvc-x64",
              "compilerArgs": [
                  "/experimental:module",
                  "/interface"
              ]
          }
      ],
      "version": 4
  }
  

  The important part is to be using MSVC, c++20, and have /experimental:module and /interface. Everything else is default.

• Logs from running C/C++: Log Diagnostics from the VS Code command palette

  • Diagnostic Log

• Logs from the language server logging

  • Language Server Log

Start with the m.cpp and u.cpp samples and the .vscode/c_cpp_properties.json configuration, then compile m.cpp with the shown MSVC C++20 module command and inspect the language-service diagnostic on t.privateMember. The work is done when the friend access produces no inaccessible-member error while the sample still compiles and links correctly.