Brian Wilkerson
35f6ce7bb0
This prevents a null exception that could otherwise occur during code completion. I think that this only impacts internal users. It's not ideal. As you can see from the tests OpType is deciding that we should be suggesting type names in places where they can't exist, but I think that's a theoretic issue because I believe that the code completion code won't access the OpType in these situations. If I'm wrong, then the failure mode will be to suggest type names that shouldn't be suggested in a couple of situations. If users do notice this behavior it should be relatively easy to tighted up the computation to only suggest the valid completions. Change-Id: I6ceb9615384371f9dcc4fd30d914c7574ed6e304 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506340 Reviewed-by: Samuel Rawlins <srawlins@google.com> Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
A framework for building plugins for the analysis server.
Warning
This package is for legacy support and is not recommended for new plugin development.
For modern plugin implementations, use the
analysis_server_pluginpackage instead.See its documentation for the latest architecture and examples.
Usage
Note: The plugin support is not currently available for general use.
Plugins are written in Dart and are run in the same VM as the analysis server. The analysis server runs each plugin in a separate isolate and communicates with the plugin using a plugin API. This API is similar to the API used by the analysis server to communicate with clients.
Plugins are automatically discovered and run by the analysis server.
This package contains support code to make it easier to write a plugin. There is a tutorial describing how to use the support in this package.
Support
Post issues and feature requests on the issue tracker.
Questions and discussions are welcome at the Dart Analyzer Discussion Group.
License
See the LICENSE file.