Support WSL project/executable

[InSyncWithFoo]

Fixes #54.

[github-actions[bot]]

Qodana Community for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked

View the detailed Qodana report

To be able to view the detailed Qodana report, you can either: - Register at [Qodana Cloud](https://qodana.cloud/) and [configure the action](https://github.com/jetbrains/qodana-action#qodana-cloud) - Use [GitHub Code Scanning with Qodana](https://github.com/jetbrains/qodana-action#github-code-scanning) - Host [Qodana report at GitHub Pages](https://github.com/JetBrains/qodana-action/blob/3a8e25f5caad8d8b01c1435f1ef7b19fe8b039a0/README.md#github-pages) - Inspect and use `qodana.sarif.json` (see [the Qodana SARIF format](https://www.jetbrains.com/help/qodana/qodana-sarif-output.html#Report+structure) for details) To get `*.log` files or any other Qodana artifacts, run the action with `upload-result` option set to `true`, so that the action will upload the files as the job artifacts: ```yaml - name: 'Qodana Scan' uses: JetBrains/qodana-action@v2024.1.5 with: upload-result: true ```

Contact Qodana team

Contact us at [qodana-support@jetbrains.com](mailto:qodana-support@jetbrains.com) - Or via our issue tracker: https://jb.gg/qodana-issue - Or share your feedback: https://jb.gg/qodana-discussions

[InSyncWithFoo]

After many, many trial-and-error cycles, I think these are the key points:

GeneralCommandLine uses Command Prompt for Windows

WSLDistribution.patchCommandLine() is used to take care of this.

However, a new problem arised from there.

PyCharm interacts with the file system via its concept of VirtualFiles

File URIs in request and response objects seem to be derived from the .getUrl() method, whose return values may not be RFC-compliant and thus invalid URIs. For example, it may emit file:////wsl$/Ubuntu/home/user instead of file://wsl.localhost/Ubuntu/home/user. To make things worse, VirtualFileManager.findFileByUrl() doesn't accept correct file: URIs.

I tackle this by replacing file:////wsl$ with file://wsl.localhost and revert as necessary.

But that's not all.

Windows 11 uses wsl.localhost, whereas Windows 10 uses wsl$

I believe there are also APIs to differentiate the two versions, but I'm blocked by a final problem.

Working directory doesn't seem to be correctly recognized

False reportMissingImports are emitted, suggesting that there are problems with either the withWorkDirectory() call, how Pyright handles it, or both.

For comparison, no such diagnostics are emitted for the same file structure on Windows.

As a bonus, a visible IllegalStateException might be thrown if your build is older than 2024.2 EAP 1, which has yet to be released.

Current progress

The latest commit (c91b226) should deal with the first two.

I asked about this on Slack about half a week ago, but no answers so far. Out of ideas for now.

[InSyncWithFoo]

Found a way: Only send (and receive) Linux paths, but reprocess those paths before passing them to the default LspServerDescriptor.findFileByUri(). This also cures the false reportMissingImports diagnostics above.