Get all problems (errors, warnings, etc.) using VSCode extensions API

[ghost]

I am creating a VSCode extension and I need a way to access all of the current errors, warnings, etc in the Problems pane but I am not even sure if the API provides access to this. I see that I can create Diagnostics and it appears that I can get those diagnostics with the DiagnosticCollection but I don't see where I can get a list of all of the errors and such. Does anyone have experience with this?

[sghung]

I am also a VSCode extension builder who wants to write automated tests for verifying a language server from the client side. Since I'm unable to programatically access the DiagnosticCollection, it is quite difficult to automate. Having additional API to access these problems would be very helpful.

[jrieken]

fyi @dbaeumer

[lggomez]

+1 to this

I'm writing an extension that performs actions based on json content and this would be very useful to make preemptive validations based on existing diagnostics

[jrieken]

Proposal for an event describing a change to markers. We should maybe think of adding a real event type as this allows for future growth

export const onDidChangeDiagnostics: Event<Uri[]>;

The proposal for reading diagnostics is a little harder because the Diagnostics-type doesn't know the resource it is targeting - therefore we use tuple-types, e.g [Uri, Diagnostics[]]. However, that doesn't work well with reading diagnostics for just one resource...

One idea is a type like a readonly-diagnostics collection. That could look like this:

export interface DiagnosticInformation {
	has(uri: Uri): boolean;
	get(uri: Uri): Diagnostic[] | undefined;
	all(): [Uri, Diagnostic[]][];
}

export namespace languages {
	export const diagnostics: DiagnosticInformation;
}

Or, a more simple approach using a callback (similar to DiagnosticsCollection#forEach). The downside of this approach is that we are inventing our own iteration protocol.

export namespace languages {
  // read one
  forEachDiagnostic(resource: Uri, callback:(resource: Uri, diagnostics: Diagnostics[]) => any):void;

  // read all
  forEachDiagnostic(callback:(resource: Uri, diagnostics: Diagnostics[]) => any):void;
}

cc @alexandrudima @dbaeumer for feedback

[dbaeumer]

@jrieken: I would definitely go with a real event type.

For the API I have a question first: are all diagnostics mirrored into the extension host? If not we need to get the async. So I would make the API dependent on that. If we need to get the async DiagnosticInformation might get a little cumbersome.

BTW: I need to add a comparable API for tasks which I would need to get async and I would like to copy what we decided to do for diagnostics.

[jrieken]

I would definitely go with a real event type.

I like, pushed a change for.

For the API I have a question first: are all diagnostics mirrored into the extension host? If not we need to get the async. So I would make the API dependent on that.

Read APIs should always be synchronous and 'no' diagnostics aren't mirrored. Afaik only the task framework is writing diagnostics outside the extension host and the current implementation doesn't provide read access to them. We have to either eagerly mirror those to the extension host or find a way for the task framework to report errors via the extension host infrastructure...

BTW: I need to add a comparable API for tasks which I would need to get async and I would like to copy what we decided to do for diagnostics.

Not sure what that means...

[jrieken]

So, this is the API I am proposing - it's little and in the same spirit of existing API (returns an array, is sync).

export interface DiagnosticChangeEvent {
  uris: Uri[];
}

export namespace languages {
  export const onDidChangeDiagnostics: Event<DiagnosticChangeEvent>;
  export function getDiagnostics(resource?: Uri): Diagnostic[];
}

The challenge with this proposal is that Diagnostics-objects don't know their location, only their range. That was a mistake and something can and should fix now by adding a location-property to diagnostic-objects, e.g.

export class Diagnostic {

  /**
   * @deprecated Use location
   */
  range: Range;

  location: Location;
  
  // ...
}

The plan is to deprecate the existing constructor and encourage extension authors to provide a location when creating diagnostics. For those that don't we can synthesise the location when a diagnostic object is added to a collection, e.g via set(uri: Uri, diagnostics: Diagnostic[] | undefined): void; or set(entries: [Uri, Diagnostic[] | undefined][]): void;

[dbaeumer]

Makes sense to me.

[jrieken]

fyi @DanTup

[julienhenry]

Thanks for the recent commits. Can you explain what to put in my package.json file to be able to use these new API methods in my extension right away?

[jrieken]

@julienhenry It is proposed API, to try it you must copy the vscode.proposed.d.ts-file into your project and then also add "enableProposedApi": true to your package.json file. That will allow you tryout proposed API locally but you cannot publish an extension using it. Still, we would love to get your feedback on this.

[jrieken]

We will ship this in April but diagnostics from the task framework are likely not accessible, see #47292