Open devoncarew opened 7 years ago
Agreed. How are clients currently using diagnostic.getDiagnostics
? (Trying to decide whether we should have a separate request.)
Atom uses it as a 'heart-beat', and to get visibility into whether the analysis server is busy and making forward progress.
VSCode and IntelliJ do not call it, but it would be useful to return some options and settings data (is the new driver being used?) along with bug reports (https://github.com/Dart-Code/Dart-Code/issues/224).
If we're talking about command-line arguments, the client already knows what the command-line looked like, so there isn't any need to send that back. Presumably the client can cache that information in order to send it with bug reports. Context-specific options, otoh, the client has no way of knowing.
I've created a PR that adds some additional info to the Dart Code error reports for https://github.com/Dart-Code/Dart-Code/issues/224.
I just JSON.stringify
the contexts so anything included in them will show up (I don't know if this is a bad idea; it looks fairly simple in my testing).
The additional info looks like this (diagnostics won't be included if we didn't get a response from the AS between the error occurring and the user clicking "Generate Report"):
The analyzer was launched with the arguments:
--client-id=DanTup.dart-code
--client-version=0.15.0-dev
Diagnostics requested after the error occurred are:
[
{
"name": "m:\\Coding\\TestStuff\\FootballGameDart-bad",
"explicitFileCount": 20,
"implicitFileCount": 4,
"workItemQueueLength": 0,
"cacheEntryExceptions": []
}
]
We should report additional info about the analysis server in the diagnostic calls (either added to diagnostic.getDiagnostics or in a separate call).
Things like whether the server was running in --enable-new-analysis-driver
btw, diagnostics.getDiagnostics actually seems to error under the new driver.. not sure if this is expected? See https://github.com/Dart-Code/Dart-Code/issues/233
Oops, Devon already reported that (#28068)!
We should report additional info about the analysis server in the diagnostic calls (either added to diagnostic.getDiagnostics or in a separate call). When generating bug reports, it would be nice to have a payload from the server to append to the report about the server's state. Things like whether the server was running in
--enable-new-analysis-driver
, whether individual contexts were running in strong mode or with generic methods enabled, ...