Add 'Suggestion' diagnostics #22204
Add 'Suggestion' diagnostics #22204
Conversation
ghost
requested review from
src/compiler/types.ts
Outdated
| @@ -4017,8 +4017,14 @@ namespace ts { | |||
| export enum DiagnosticCategory { | |||
| Warning, | |||
| Error, | |||
| Info, | |||
There was a problem hiding this comment.
I would call it Suggession. Info and Message are pretty much the same thing.
There was a problem hiding this comment.
Suggession -> Suggestion
There was a problem hiding this comment.
FWIW, Roslyn calls it Info. What is the difference between Info and Message? Is Message actually Telemetry?
There was a problem hiding this comment.
Message is like description of a quick fix. user never sees that as a Diagnostic really.
There was a problem hiding this comment.
This isn't quite what Roslyn calls Info, so I'm fine with either Info or Suggestion (or Hint, which appears to be the VS Code name).
There was a problem hiding this comment.
I'd rather be consistent, but if we plan to have more-specific categories than Info in the future, Suggestion is fine with me.
src/server/protocol.ts
Outdated
| @@ -2121,7 +2135,7 @@ namespace ts.server.protocol { | |||
| text: string; | |||
|
|
|||
| /** | |||
| * The category of the diagnostic message, e.g. "error" vs. "warning" | |||
| * The category of the diagnostic message. This is the lower-case of a DiagnosticCategory member. | |||
There was a problem hiding this comment.
the generated protocol.d.ts does not have DiagnosticCategory. so I would keep the comment in there.
One other thing also is we allow extensions to set it, so it is possible that there are other values here. so a union of string literals would be too restrictive for clients.
src/server/session.ts
Outdated
| if (diags) { | ||
| const bakedDiags = diags.map((diag) => formatDiag(file, project, diag)); | ||
| this.event<protocol.DiagnosticEventBody>({ file, diagnostics: bakedDiags }, "syntaxDiag"); | ||
| // TODO: why do we check for diagnostics existence here, but in semanticCheck send unconditionally? |
There was a problem hiding this comment.
we should report both unconditionally
src/services/infoDiagnostics.ts
Outdated
| @@ -0,0 +1,8 @@ | |||
| /* @internal */ | |||
| namespace ts { | |||
| export function infoDiagnostics(sourceFile: SourceFile): Diagnostic[] { | |||
There was a problem hiding this comment.
consider naming it compute*Diagnostics
|
Just a few comments about the name of the enum value. @amcasey any comments? |
src/compiler/types.ts
Outdated
| @@ -4017,8 +4017,14 @@ namespace ts { | |||
| export enum DiagnosticCategory { | |||
| Warning, | |||
| Error, | |||
| Info, | |||
There was a problem hiding this comment.
This isn't quite what Roslyn calls Info, so I'm fine with either Info or Suggestion (or Hint, which appears to be the VS Code name).
src/server/protocol.ts
Outdated
| arguments: InfoDiagnosticsSyncRequestArgs; | ||
| } | ||
|
|
||
| export interface InfoDiagnosticsSyncRequestArgs extends FileRequestArgs { |
There was a problem hiding this comment.
Can/should interface declarations be shared across the various kinds of diagnostics?
src/server/session.ts
Outdated
| if (diags) { | ||
| const bakedDiags = diags.map((diag) => formatDiag(file, project, diag)); | ||
| this.event<protocol.DiagnosticEventBody>({ file, diagnostics: bakedDiags }, "syntaxDiag"); | ||
| // TODO: why do we check for diagnostics existence here, but in semanticCheck send unconditionally? |
| const errorCodes = [Diagnostics.File_is_a_CommonJS_module_it_may_be_converted_to_an_ES6_module.code]; | ||
| registerCodeFix({ | ||
| errorCodes, | ||
| getCodeActions(context) { |
| @@ -29,4 +29,4 @@ verify.completionListContains("name"); | |||
| edit.insert("name;\nsausages."); | |||
| verify.completionListContains("eggs"); | |||
| edit.insert("eggs;"); | |||
| verify.noErrors(); | |||
| verify.noErrors({ ignoreInfoDiagnostics: true }); | |||
There was a problem hiding this comment.
Personally, I would expect noDiagnostics to mean "no diagnostics of any severity" and noErrors to mean "no diagnostics of error severity".
|
I'm going to try hacking up my local VS build to confirm that I can consume this. I don't expect issues. |
|
I've created an internal PR that makes VS consume the new API. LGTM |
|
I'm fine with either "Info" or "Suggestion" and I've already confirmed that I can consume the new API from VS. |
ghost
mentioned this pull request
Fixes #19392
Previously we had just syntax and semantic diagnostics. This adds a third layer of "info" diagnostics. They are only a part of services, so do not impact command line compilation.
Now when the editor sends us a "geterr" request, we will send 3 responses for "syntaxDiag", "semanticDiag", and "infoDiag". (See changes to
updateErrorCheck.) All return a Diagnostic[].For use from Visual Studio, this also adds a "infoDiagnosticsSync" command. (@amcasey or would it be easier to just send it along with "semanticDiagnosticsSync"? Might impact performance as we add more info diagnostics though.)
For now there is only one info diagnostic, for a file that could be converted to commonJs. Moved the
convertToEs6Modulerefactoring to a codefix.CC @mjbvz