First step of support for parsing and ignoring generic methods.

pkg/compiler/lib/src/parser/element_listener.dart

Index: pkg/compiler/lib/src/parser/element_listener.dart
diff --git a/pkg/compiler/lib/src/parser/element_listener.dart b/pkg/compiler/lib/src/parser/element_listener.dart
index 48bfae3139327643294a3ba0855a560138244dde..7b1f18837e309aa449d8c20a47a01ebb52ea5f5d 100644
--- a/pkg/compiler/lib/src/parser/element_listener.dart
+++ b/pkg/compiler/lib/src/parser/element_listener.dart
@@ -64,6 +64,19 @@ class ScannerOptions {
   const ScannerOptions({this.canUseNative: false});
 }
 
+/// Options used for parsing.
+///
+/// Use this to conditionally support certain constructs, e.g.,
+/// experimental ones.
+class ParserOptions {

[ahe, 2016/02/23 08:05:26]

Is this class really needed?

[eernst, 2016/02/23 12:40:45]

Here's how I concluded that this class was needed:

In several locations a sub-parser is created (partial_elements.dart line 433 and
500, diet_parser_task.dart line 46, etc.). Such a sub-parser will need the same
customization as existing parsers (for instance, a `ClassElementParser` should
support generic methods if it is created in a situation where generic methods
are supported in general), but no information is available in certain of these
locations (e.g., sub-parsers are created outside the scope of any existing
parser in 'partial_elements.dart', so there is no `enableGenericMethods` field
in scope).

I made an attempt to pass the required information along in arguments, but this
causes arguments to be threaded through listeners and through lots of
`parseNode` methods, and there is seemingly no end to the places where extra
arguments have to be added.

In contrast, extending `Parsing` with the parser option information solves the
problem completely and concisely. In line with the `scannerOptions` of
`Parsing`, I felt that the most consistent approach would be to let it have a
similar set of `parserOptions`, and consequently the `ScannerOptions` class gets
a `ParserOptions` sibling.

I believe that future parser options could easily and comprehensibly be passed
around using this setup (so I preferred that over an alternative like having
`enableGenericMethods` as a field directly in `Parsing`).

An alternative worth considering would of course be to unify `ParserOptions` and
`ScannerOptions` and keep all those syntax related options in a single
`syntaxOptions` of type `SyntaxOptions`.

+  final bool enableConditionalDirectives;
+  final bool enableGenericMethods;
+
+  const ParserOptions(
+      {this.enableConditionalDirectives: false,
+       this.enableGenericMethods: false});
+}
+
 /**
  * A parser event listener designed to work with [PartialParser]. It
  * builds elements representing the top-level declarations found in