[mlir-vscode] Fix processing of files not within the workspace

[rriddle]

Summary

In a previous commit we added proper support for separate configurations
per workspace folder, but that effectively broke support for processing out-of-workspace
files. Given how useful this is (e.g. when iterating on a test case in /tmp), this
commit refactors server creation to support this again. We support this case using
a "fallback" server that specifically handles files not within the workspace. This uses
the configuration settings for the current workspace itself (not the specific folder).

[jpienaar]

mlir/utils/vscode/src/mlirContext.ts

132

And all of this is required as we can have different dialects linked into different LSPs? (so PDLL doesn't need this?). And so to avoid requiering custom concatted LSP servers with deps, one can have one per workspace? (well probably that doesn't completetly avoid it as a user could still be using the union of the dialects in some client). It made sense when you added this, but now I'm wondering benefit vs implementation cost.

[rriddle]

mlir/utils/vscode/src/mlirContext.ts

132

It's not just about concatted server deps, it also applies to the the version of LLVM that is checked out. The way that my workspace is structured (and I assume I'm not alone) is that I have a workspace folder for the different projects I develop (e.g. one for LLVM, one for Modular AI, etc.). Not all of these have an overlap of deps (Modular doesn't register the MLIR test dialect for example), and not all have the same version (i.e. git checkout) of every dialect. I've also been bitten by PDLL the same way, where the checkout of LLVM has a different version of PDLL than the one I have in other projects. If we don't allow multiple servers, workspaces like mine generally just can't work. This is especially true given that the downstream projects are often further behind HEAD than my LLVM checkout (meaning that even if I do concat all the deps, the server doesn't understand LLVM HEAD).

[silvas]

Thanks for fixing this River :)

mlir/utils/vscode/src/mlirContext.ts

143

maybe my JS/TS is out of date, but this vscode.EnvironmentVariableMutatorType looks like an no-op statement to me.

[rriddle]

mlir/utils/vscode/src/mlirContext.ts

143

Nice catch (not sure how that slipped in there).

[jpienaar]

SG, thanks for the explanation

mlir/utils/vscode/src/mlirContext.ts

async activate(outputChannel: vscode.OutputChannel,
                  warnOnEmptyServerPath: boolean) {
     // Start clients for each workspace folder.
     if (vscode.workspace.workspaceFolders &&
         vscode.workspace.workspaceFolders.length > 0) {
       for (const workspaceFolder of vscode.workspace.workspaceFolders) {
         this.workspaceFolders.push(await this.activateWorkspaceFolder(
             workspaceFolder, outputChannel, warnOnEmptyServerPath));
       }
-    } else {
-      this.workspaceFolders.push(await this.activateWorkspaceFolder(
-          null, outputChannel, warnOnEmptyServerPath));
-    }
-  }
+    }
 
   /**
    *  Activate the context for the given workspace folder, and start the
    *  language clients.
    */
   async activateWorkspaceFolder(workspaceFolder: vscode.WorkspaceFolder,
                                 outputChannel: vscode.OutputChannel,
                                 warnOnEmptyServerPath: boolean):
async startLanguageClient(workspaceFolder: vscode.WorkspaceFolder,
     // Configure file patterns relative to the workspace folder.
     let filePattern: vscode.GlobPattern = '**/*.' + languageName;
     let selectorPattern: string = null;
     if (workspaceFolder) {
       filePattern = new vscode.RelativePattern(workspaceFolder, filePattern);
       selectorPattern = `${workspaceFolder.uri.fsPath}/**/*`;
     }
 
+    // Configure the middleware of the client. This is sort of abused to allow
+    // for defining a "fallback" language server that operates on non-workspace
+    // folders. Workspace folder language servers can properly filter out
+    // documents not within the folder, but we can't effectively filter for
+    // documents outside of the workspace. To support this, and avoid having two
+    // servers targeting the same set of files, we use middleware to inject the
+    // dynamic logic for checking if a document is in the workspace.
+    let middleware = {};
+    if (!workspaceFolder) {
+      middleware = {
+        didOpen : (document, next) => {
+          vscode.EnvironmentVariableMutatorType
+          if (!vscode.workspace.getWorkspaceFolder(document.uri)) {
+            next(document);
+          }
+        }
+      };
+    }
+
     // Configure the client options.
     const clientOptions: vscodelc.LanguageClientOptions = {
       documentSelector : [
         {scheme : 'file', language : languageName, pattern : selectorPattern}
       ],
       synchronize : {
         // Notify the server about file changes to language files contained in
         // the workspace.
         fileEvents : vscode.workspace.createFileSystemWatcher(filePattern)
       },
       outputChannel : outputChannel,
-      workspaceFolder : workspaceFolder
+      workspaceFolder : workspaceFolder,
+      middleware : middleware
     };
 
     // Create the language client and start the client.
     let languageClient = new vscodelc.LanguageClient(
         languageName + '-lsp', clientTitle, serverOptions, clientOptions);
     this.subscriptions.push(languageClient.start());
     return [ languageClient, serverPath ];
   }