This makes it easier to follow class hierarchies and understand where a
class is changing the interface. I hit this when I found a class that
had the annotation on some methods it was overriding, but not all, which
made it confusing.
Prepares for adding the lint rule and enforcing it.
40% of overridden methods were annotated - add annotations to the remaining 60%.
Change-Id: I02472f4b6c5026a820cf9ff1a7ada663a60f1868
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96666
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Since we switched to the CFE we no longer use this, the CFE recomputes the package-configuration internally.
Change-Id: Icdc2a3eeff1aa75e560157ecf0d5320208096d21
Reviewed-on: https://dart-review.googlesource.com/c/84362
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Using immutable options objects was nice, but it came with a tax every time we added or modified
options (often having to edit 5 locations). I'm now using a mutable object and
default values are inline with the field declaration.
Change-Id: I92768f0ff50a4140271dc0ebfa3b615c94a57e4d
Reviewed-on: https://dart-review.googlesource.com/48446
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
When landed, CL 1789553003 turned out to cause bot failures because
some libraries outside the compiler are importing compiler libraries
which have been updated. For instance, the tests in 'compiler/dart2js'
depend on several internal elements of the 'dart2js' compiler.
This CL updates these external dependents to work with the modified
library structure and class APIs of the compiler. A small adjustment
was applied to 'dart2js_incremental' as well.
No further dependents are believed to exist: Grepping in sdk for
relevant imports does not reveal any further imports of any of the
libraries in the compiler where the "interface" has changed, and
external clients are not supported (that is, imports in arbitrary
github repositories may or may not break if they use the compiler
internals, but we do not support this type of dependency so we won't
do anything to protect them against that type of breakage).
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1864433004 .
In preparation for support for generic methods (with an associated
command line option), this CL introduces a `ParserOptions` class and
uses that to pass the existing option `enableConditionalDirectives` to
all parsers. With that, the addition of an `enableGenericMethodSyntax`
option will be concise and well localized.
It is necessary to keep a `ParserOptions` object in `Parsing`, because
that's the only convenient channel for providing the options to the new
`Parser` and `ClassElementParser` created from the top-level function
`parse` in 'partial_elements.dart', and a from
`PartialClassElement.parseNode`, respectively.
The `ParserOptions` class is located in 'parser.dart'; from the current
import structure the most natural choice might be to put it in
'element_listener.dart', but considering the nature of that file it
seems less natural: What does `ParserOptions` have to do with element
listeners? So I put it in 'parser.dart', even though this causes a few
additional import statements.
R=johnniwinther@google.com, sigmund@google.com
Review URL: https://codereview.chromium.org/1789553003 .
Main changes are in the added files, compiler/compiler.dart, src/compiler.dart and src/apiimpl.dart.
Start by looking at compiler/compiler_new.dart and compiler/compiler.dart.
BUG=
R=floitsch@google.com
Review URL: https://codereview.chromium.org//1235563003.
Kevin Moore