[PATCH] D70041: register cuda language activation event and activate for .cuh files

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.


================
Comment at: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts:92
+  // *not* load itself automatically on '.cu' and '.cuh' files.
+  const cudaFilePatterns: {scheme: string, pattern: string}[] = [
+    {scheme : 'file', pattern : '**/*.{cu}'},
----------------
ptaylor wrote:
> hokein wrote:
> > I think we could simplify the code, we could move this part to the package.json under the `contributes` umbrella, something like
> > 
> > ```
> >   "contributes": {
> >         "languages": [
> >             {
> >                 "id": "cuda",
> >                 "filenamePatterns": [
> >                     "**/*.{cu}",
> >                     "**/*.{cuh}",
> >                 ],
> >             }
> >         ]
> > ```
> > 
> > then in the extension.ts, we only need an entry `{ scheme: 'file', language: 'cuda' }` when initailizing the clientOptions.
> Yes that's an option. I chose this approach to stay consistent with the current behavior, because `vscode-clangd` can do CUDA intellisense and refactoring, it doesn't contribute the CUDA grammar definitions for syntax highlighting.
> 
> The VSCode docs aren't clear on whether multiple extensions can contribute separate features for the same language, or what happens when two plugins both contribute languages with the same `languageId`.
> I chose this approach to stay consistent with the current behavior.

Yes, I was not ware of this approach before. 

> The VSCode docs aren't clear on whether multiple extensions can contribute separate features for the same language, or what happens when two plugins both contribute languages with the same languageId.

The [vscode doc](https://code.visualstudio.com/api/references/contribution-points#contributes.languages) says `ontributes.languages` can enrich the knowledge about vscode, but doesn't mention about what if there are multiple extensions contribute for the same language, but from our experience (clangd extension also contributes to `cpp` language for taking some file patterns into account), it seems no problem so far. 

Anyway, I'm also fine with the current approach. 


================
Comment at: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts:103
+            // language id. This should be forwards-compatible if VSCode
+            // starts shipping CUDA language support. A working 'cuda'
+            // language definition is provided by kriegalex.vscode-cudacpp.
----------------
I'd drop `A working ....`, I don't know much about vscode-cudacpp. But in theory, clangd extension will work with any extension which provides the `cuda` language definition.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70041/new/

https://reviews.llvm.org/D70041