OptionsValidator plugin extension and linter service.

pkg/analyzer/lib/src/task/options.dart

Index: pkg/analyzer/lib/src/task/options.dart
diff --git a/pkg/analyzer/lib/src/task/options.dart b/pkg/analyzer/lib/src/task/options.dart
index c80687bd88967f86b884e324dc7d2f06a9554716..80ac44f714593cafc19bd5acfeb3558165b3b79b 100644
--- a/pkg/analyzer/lib/src/task/options.dart
+++ b/pkg/analyzer/lib/src/task/options.dart
@@ -5,6 +5,7 @@
 library analyzer.src.task.options;
 
 import 'package:analyzer/analyzer.dart';
+import 'package:analyzer/plugin/options.dart';
 import 'package:analyzer/source/analysis_options_provider.dart';
 import 'package:analyzer/src/generated/engine.dart';
 import 'package:analyzer/src/generated/source.dart';
@@ -27,6 +28,16 @@ class AnalyzerOptionsValidator extends TopLevelOptionValidator {
       : super('analyzer', const ['exclude', 'plugins', 'strong-mode']);
 }
 
+/// Convenience class for composing validators.
+class CompositeValidator extends OptionsValidator {
+  final List<OptionsValidator> validators;
+  CompositeValidator(this.validators);
+
+  @override
+  void validate(ErrorReporter reporter, Map<String, YamlNode> options) =>
+      validators.forEach((v) => v.validate(reporter, options));
+}
+
 /// A task that generates errors for an `.analysis_options` file.
 class GenerateOptionsErrorsTask extends SourceBasedAnalysisTask {
   /// The name of the input whose value is the content of the file.
@@ -96,12 +107,15 @@ class LinterOptionsValidator extends TopLevelOptionValidator {
 /// Validates options defined in an `.analysis_options` file.
 class OptionsFileValidator {
   // TODO(pq): move to an extension point.

[pquitslund, 2015/10/23 22:03:46]

If we're happy with the extension point, these can get moved to proper
contributions.

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

Doesn't this CL already cause both of these to be contributed?

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

Yes.  Sorry I wasn't clear.  Notice that here the base analyzer and linter ones
are just shoved into the _validators array (unlike the one elsewhere to validate
lint rules).  When we're happy with the extension point we can discuss whether
we want the ceremony of registering them via a plugin contribution.  

I'm inclined to for consistency.  What do you think?

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

I'm not sure we need to wait until we're happy with it (and it's part of the
public API now, so I hope we're happy with it).
I think we should use the plugin support where ever its reasonable (and I think
it's reasonable here).

-  static final List<OptionsValidator> _validators = [
-    new AnalyzerOptionsValidator(), new LinterOptionsValidator()
+  final List<OptionsValidator> _validators = [
+    new AnalyzerOptionsValidator(),
+    new LinterOptionsValidator()
   ];
 
   final Source source;
-  OptionsFileValidator(this.source);
+  OptionsFileValidator(this.source) {
+    _validators.addAll(AnalysisEngine.instance.optionsPlugin.optionsValidators);
+  }
 
   List<AnalysisError> validate(Map<String, YamlNode> options) {
     RecordingErrorListener recorder = new RecordingErrorListener();
@@ -111,12 +125,6 @@ class OptionsFileValidator {
   }
 }
 
-/// Validates options.
-abstract class OptionsValidator {
-  /// Validate [options], reporting any errors to the given [reporter].
-  void validate(ErrorReporter reporter, Map<String, YamlNode> options);
-}
-
 /// Validates top-level options. For example,
 ///     plugin:
 ///       top-level-option: true