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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to