OptionsValidator plugin extension and linter service.

pkg/analyzer/lib/plugin/options.dart

Index: pkg/analyzer/lib/plugin/options.dart
diff --git a/pkg/analyzer/lib/plugin/options.dart b/pkg/analyzer/lib/plugin/options.dart
index fb99a5070f5717c71d3992c6967c9ed63f9857d5..d8cb1f96ecd6f779969fc0862b3a78cbe8ce6df7 100644
--- a/pkg/analyzer/lib/plugin/options.dart
+++ b/pkg/analyzer/lib/plugin/options.dart
@@ -6,6 +6,7 @@
 /// analysis options file.
 library analyzer.plugin.options;
 
+import 'package:analyzer/analyzer.dart';

[Brian Wilkerson, 2015/10/24 15:32:17]

Whatever we're importing from here is exported from somewhere else. I'd prefer
to import it from the original library rather than indirectly.

[pquitslund, 2015/10/26 15:48:59]

Interesting. Maybe we should cook up a lint for this?  Or maybe it doesn't come
up often enough?

[Brian Wilkerson, 2015/10/26 16:07:14]

I suspect that this doesn't come up very often. It's generally only a problem if
a type is made visible from two or more public libraries (and because of
history, that isn't the case here), which probably doesn't happen very often.
And even then, it isn't clear that it would matter which one it was imported
from. I think this is just a weird case.

 import 'package:analyzer/src/generated/engine.dart';
 import 'package:analyzer/src/plugin/options_plugin.dart';
 import 'package:plugin/plugin.dart';
@@ -18,6 +19,13 @@ final String OPTIONS_PROCESSOR_EXTENSION_POINT_ID = Plugin.join(
     OptionsPlugin.UNIQUE_IDENTIFIER,
     OptionsPlugin.OPTIONS_PROCESSOR_EXTENSION_POINT);
 
+/// The identifier of the extension point that allows plugins to validate
+/// options defined in the analysis options file. The object used as an
+/// extension must be an [OptionsValidator].
+final String OPTIONS_VALIDATOR_EXTENSION_POINT_ID = Plugin.join(
+    OptionsPlugin.UNIQUE_IDENTIFIER,
+    OptionsPlugin.OPTIONS_VALIDATOR_EXTENSION_POINT);
+
 /// Processes options defined in the analysis options file.
 ///
 /// The options file format is intentionally very open-ended, giving clients
@@ -61,3 +69,12 @@ abstract class OptionsProcessor {
   /// provided as well to allow for context-specific configuration.
   void optionsProcessed(AnalysisContext context, Map<String, YamlNode> options);
 }
+
+/// Validates options as defined in an analysis options file.
+///
+/// See [OptionsProcessor] for a description of the options file format.
+///

[Brian Wilkerson, 2015/10/24 15:32:17]

In the server plugins, I've been adding text indicating what clients can and
cannot do with the public classes. For an interface like this, the text is:

Clients may implement this class when implementing plugins.

[pquitslund, 2015/10/26 15:48:59]

Cool.  Added.  Do you have a doc anywhere with these guidelines?  If not, maybe
added to the CONTRIBUTING doc?

[Brian Wilkerson, 2015/10/26 16:07:14]

No. We've been discussing the possibility of adding annotations in place of, or
in addition to, these comments.
Maybe. Is it normally customized? It looks like boiler-plate to me.

+abstract class OptionsValidator {
+  /// Validate [options], reporting any errors to the given [reporter].
+  void validate(ErrorReporter reporter, Map<String, YamlNode> options);
+}