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>
This includes Fasta, tools and observatory, so the checked-in SDK must
have the lower-case constants.
Change-Id: I8380ad041ad058f7d02ae19caccfecd434d13d75
Reviewed-on: https://dart-review.googlesource.com/50201
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This CL creates the initial dart2js-specific CFE entry point.
It is currently mostly a matter of copying the dart2js code for running the
front-end into the front-end, although it also applies a workaround for
making batch-mode faster.
Running the same dart2js with kernel tests as on the bots locally I get
this:
* Before: [09:11 | 100% | +10507 | - 0]
* Now [04:46 | 100% | +10507 | - 0]
Change-Id: I68f147fd7aadb0281807b4688b9f6fdc5aa24c28
Reviewed-on: https://dart-review.googlesource.com/25300
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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.
Stephen Adams