Windows IDEA WSL support

[dpoluyanov]

Hi,

JetBrains team released WSL support in 2021.1 (see https://www.jetbrains.com/help/idea/how-to-use-wsl-development-environment-in-product.html )
While it is still has issue with symlinks: https://youtrack.jetbrains.com/issue/IDEA-253253
other parts of wsl interoperability works like a charm: one could open and work on project stored in linux (through wsl) from windows version of IntelliJ IDEA, and even integrated idea-terminal opens linux shell console instead of powershel.

But even in such smooth integration working with Bazel projects is hard, because:

1. It is not possible to choose & launch Bazel linux binary from Windows version of IntelliJ (because process executes in windows runtime) (see Bazel sync fails when importing C++ project on WSL #3098)
2. there are difference in file paths, produced from linux version of Bazel and wsl provided paths from windows. Every file is prefixed with \\wsl$\<distro-name> and has windows file separator (\ instead of /), e.g. /home/<user>/project/WORKSPACE will be accessible from \\wsl$\<distro-name>\home\<user>\project\WORKSPACE.
3. due to p2 IntelliJ bazel plugin could not determine project paths and dependencies (see Allow Bazel plugin to use WSL #3063)
4. and last some Bazel commands are not correctly escaped, like one fixed in IntelliJ: Use single quote instead of double quote for sync query string in Windows. #2976

In order to fix these issues without rewriting a lot of parts of Bazel IntelliJ plugin (I understand that it is hardly be accepted by your team) I wrote a small go program https://github.com/dpoluyanov/bazel-wsl, which acts as Bazel binary for IntelliJ Bazel plugin and translates all passed commands to wsl default linux distro (through wsl command), so every call from plugin to bazel, like bazel info ... will be translated to wsl bazel info ..., with some patching around file paths and rewriting build event output once it is produced by linux bazel.
It could be some step toward to #113 with caveat that it is not pure windows native build, but just an ability to work with bazel from Windows machines via transparent WSL backed linux VM.

There is one issue with jdeps resolution that I'd found:
https://github.com/bazelbuild/intellij/blob/master/base/src/com/google/idea/blaze/base/sync/workspace/ArtifactLocationDecoderImpl.java#L105
It is some workaround (which I couldn't find reason for) in resolving path to SourceArtifact through checking linux-specific file separator and because JdepsFileReader adds target to map only if it is instance of OutputArtifact (which SourceArtifact is not extends) currently in case of working via wsl plugin resolves jdeps file into SourceArtifact (jdep file has prefix bazel-out\k8-fastbuild\...) and skips its loading.

I've created a small patch to change this behaviour and would like to ask: if it could be accepted into upstream repository in some way or there is another change which could be proposed in order to correctly find & load jdeps files in case of working from windows via WSL?

Index: base/src/com/google/idea/blaze/base/sync/workspace/ArtifactLocationDecoderImpl.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/base/src/com/google/idea/blaze/base/sync/workspace/ArtifactLocationDecoderImpl.java b/base/src/com/google/idea/blaze/base/sync/workspace/ArtifactLocationDecoderImpl.java
--- a/base/src/com/google/idea/blaze/base/sync/workspace/ArtifactLocationDecoderImpl.java	(revision 75c37dc96bdd4a9a4f8a74d4b50aa1fc4de51902)
+++ b/base/src/com/google/idea/blaze/base/sync/workspace/ArtifactLocationDecoderImpl.java	(date 1639304380850)
@@ -101,9 +101,17 @@
    */
   private BlazeArtifact outputArtifactFromExecRoot(ArtifactLocation location) {
     // exec-root-relative path of the form 'blaze-out/mnemonic/genfiles/path'
+    // or blaze-out\mnemonic\genfiles\path
+    char separator;
+    if(blazeInfo.getExecutionRoot().getPath().startsWith("\\\\wsl")) {
+      separator = '\\';
+    } else {
+      separator = '/';
+    }
+
     String execRootPath = location.getExecutionRootRelativePath();
-    int ix1 = execRootPath.indexOf('/');
-    int ix2 = execRootPath.indexOf('/', ix1 + 1);
+    int ix1 = execRootPath.indexOf(separator);
+    int ix2 = execRootPath.indexOf(separator, ix1 + 1);
     if (ix2 == -1) {
       return new SourceArtifact(decode(location));
     }

It also could help with #3063 and #3098 in some way

[absalvado]

What's the current state of this? I was also trying to use Bazel in Clion for a project inside my WSL documents but I'm getting the following error:

[dpoluyanov]

We've ended up with building our own copy of plugin for IntelliJ with small wrapper program around bazel

[joaogarcia940]

any news regarding this?

[stabai]

We've ended up with building our own copy of plugin for IntelliJ with small wrapper program around bazel

@dpoluyanov any chance you could open source this?

[dpoluyanov]

I've opensourced it there https://github.com/dpoluyanov/bazel-wsl

[absalvado]

Hello @dpoluyanov,

First of all thank you very much for sharing your solution. 👍

I'd like to know if after having your bazel setup if you also found this kind of issues when syncinc your project in IDEA?

[dpoluyanov]

This is a common problem for our bazel-wsl setups and we have two consequent steps to mitigate this issue:

• First of all, we create separate windows.bazelproject with enabled shard_sync and reduced value for target_shard_size to 300 (1000 by default), see https://ij.bazel.build/docs/project-views.html#target_shard_size.
  So our windows.bazelproject looks like:

import baze.bazelproject # common settings for all projects

shard_sync: true
target_shard_size: 300

• Second step is to set LongPathsEnabled to 1 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
  Look at https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later for .reg file

[absalvado]

Thank you very much! It worked on my side 🎉

[ofey404]

@dpoluyanov Thank you! Have starred your project.