New source locations were added for field initializers to support
upcoming primary constructor work.
See: https://dart-review.googlesource.com/c/sdk/+/468780
This change ensures the initializer assignment statements we add to
the constructor body are fully mapped.
Without this change the new initializer assignment wasn't getting a
mapping so it continued from whatever appeared before it.
Change-Id: Id6ba0619e49e4a517ea36ffa728cf0c1502a14e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469300
Auto-Submit: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This reverts commit c616db31d2.
Reason for revert: Fix landed downstream in Flutter engine: https://github.com/flutter/flutter/pull/180127
Original change's description:
> Revert "[ DDC / CFE ] Add support for allowing imports of unsupported libraries"
>
> This reverts commit b5e60be49d.
>
> Reason for revert: broke Flutter web engine tests
>
> Original change's description:
> > [ DDC / CFE ] Add support for allowing imports of unsupported libraries
> >
> > This change adds support for allowing for imports of unsupported
> > platform-specific libraries when the
> > `--include-unsupported-platform-library-stubs` flag is provided to the
> > CFE.
> >
> > This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
> > `TargetFlags`, which `Target`s can use to conditionally return different
> > `DartLibrarySupport` objects with different supported/unsupported
> > library sets.
> >
> > A `checkForUnsupportedDartColonImports` function has been added to
> > `Target` that uses the value of `dartLibrarySupport` to determine if
> > there's any unsupported library imports. This function is called after
> > the various transformation operations provided by the `Target`
> > implementation, meaning the import of an unsupported library specified
> > in `dartLibrarySupport` will now result in a compilation error (this
> > includes `dart:mirrors` imports for VM targets when mirrors are
> > disabled, which was previously handled by the VM itself).
> >
> > Related to https://github.com/dart-lang/sdk/issues/62125
> >
> > TEST=Tests added / modified
> >
> > Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
> > Reviewed-by: Nicholas Shahan <nshahan@google.com>
> > Reviewed-by: Johnni Winther <johnniwinther@google.com>
> > Commit-Queue: Ben Konyi <bkonyi@google.com>
>
> Change-Id: I0b59f00e55a2424f783351abd977eb38409ce01f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469100
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: I1ae2eac675432286aebabea3c1f58caf35a27fbb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469240
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This reverts commit b5e60be49d.
Reason for revert: broke Flutter web engine tests
Original change's description:
> [ DDC / CFE ] Add support for allowing imports of unsupported libraries
>
> This change adds support for allowing for imports of unsupported
> platform-specific libraries when the
> `--include-unsupported-platform-library-stubs` flag is provided to the
> CFE.
>
> This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
> `TargetFlags`, which `Target`s can use to conditionally return different
> `DartLibrarySupport` objects with different supported/unsupported
> library sets.
>
> A `checkForUnsupportedDartColonImports` function has been added to
> `Target` that uses the value of `dartLibrarySupport` to determine if
> there's any unsupported library imports. This function is called after
> the various transformation operations provided by the `Target`
> implementation, meaning the import of an unsupported library specified
> in `dartLibrarySupport` will now result in a compilation error (this
> includes `dart:mirrors` imports for VM targets when mirrors are
> disabled, which was previously handled by the VM itself).
>
> Related to https://github.com/dart-lang/sdk/issues/62125
>
> TEST=Tests added / modified
>
> Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
Change-Id: I0b59f00e55a2424f783351abd977eb38409ce01f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469100
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This change adds support for allowing for imports of unsupported
platform-specific libraries when the
`--include-unsupported-platform-library-stubs` flag is provided to the
CFE.
This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
`TargetFlags`, which `Target`s can use to conditionally return different
`DartLibrarySupport` objects with different supported/unsupported
library sets.
A `checkForUnsupportedDartColonImports` function has been added to
`Target` that uses the value of `dartLibrarySupport` to determine if
there's any unsupported library imports. This function is called after
the various transformation operations provided by the `Target`
implementation, meaning the import of an unsupported library specified
in `dartLibrarySupport` will now result in a compilation error (this
includes `dart:mirrors` imports for VM targets when mirrors are
disabled, which was previously handled by the VM itself).
Related to https://github.com/dart-lang/sdk/issues/62125
TEST=Tests added / modified
Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Embeds the size of the original Dart source files and the output
JavaScript files into an argument of the `defineLibrary()` method.
Following changes will add the usages of these values to the embedder.
Change-Id: Ibbfaa9f559248f391df6a733a0f8621f3e9edd83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467420
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
A hot restart should create a fresh compile and reset the chain of
history for hot reload changes. In the "standalone" test suite
(without the use of the frontend server) this should be achieved by
not passing the previous .dill file when compiling with DDC.
Change-Id: If729e62d3f65fd263d5b40d5dad9a5d4ed0d5839
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/450184
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Given the existing assumptions that original source files will be
served in a directory structure similar to layout defined by the
package_config.json but without `lib/` directories this change
attempts to detect when a source map contains sources from multiple
lib directories and clean them up from the relative paths.
The strategy used relies on passing a package_config.json as a signal
to detect when sources come from different packages.
Fixes: https://github.com/dart-lang/webdev/issues/1692
Issue: https://github.com/dart-lang/sdk/issues/40251
Change-Id: I6b82b33bae485d74fc61ef118dbe9ffddafab9a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456500
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This CL reduces the noise of future CFE experiments in the
backends. Whenever new nodes will be added as an experiment, the
related exception-throwing implementations will be added to the
mixins, eliminating the need to add the visit methods to the backend
code directly. The experimental type addresses a similar issue in
exhaustive switch statements and expressions.
TEST=existing
Change-Id: I1a021e11a159a992500c42287cbe6ef027bf54a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455080
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Treats async code like function expressions when adding extra
checks for correctness after a hot reload. This is intended to handle
the cases where code that was statically sound and enqueued before the
reload actually runs after a reload when the soundness may no longer
be valid.
Change-Id: I42cd010175126748937d7df830875bc5b850a565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444368
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Similar to https://dart-review.googlesource.com/c/sdk/+/445540 this
avoids compilation timeouts by avoiding recompiling the receiver in long
chains of invocations.
Guards all of the soundness checking behind a single generation check.
This was already true for nested calls but not for chains of invocations.
This also resolves a correctness issue where sub expressions of the
receiver in chained calls would be evaluated multiple times at runtime.
Change-Id: Iaf192a639e90d77995da55c7fa9c248e7bb93491
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/450183
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Turns out we'll sometimes be given the script uri as a package uri,
so we have to support that.
To further complicate things we're not necessarily given a package
config to translate from so we need to use the kernel component as a
backup.
Change-Id: I06ceb136b0b03164aaf7412d5332ae9c4c3338c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447220
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
For expression evaluation we want to be "more than dart" in that if for
instance we can see (in the debugger) that a List contains `B`s (even
if it's typed as containing `A`s) we'd like to be able to access things
on `B` (without manually having to cast to either `B` or `dynamic`).
Furthermore - when we in the debugger can see that it's a `B`, and that
`B` has, say, a field `_privateField` or a method `_privateMethod` we'd
like to be able to access that even if `B` is in another library.
This CL - for expression evaluation - makes dynamic accesses and calls
where we would normally issue a "missing getter" (etc) error, and tries
to create a `Name` so private access is possible.
Change-Id: I887318a50413e9a5f11ec685b27719edd312dca0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446260
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Currently _emitArgumentList handles arguments for Dart
members, JS interop members, and object literal constructors.
It requires an Arguments node, which we end up synthesizing,
which messes with parent pointers erroneously. We also have
to separate out the arguments and do additional checks later
to detect whether the arguments passed correspond to an
object literal constructor.
Instead, we should create the resulting expression directly
in a helper method. A map is passed so that the names of
arguments can be easily changed when we handle @JS renaming
on object literal constructors. Lastly, we need to avoid
wrapping the values with assertInterop in the case where the
constructor is from a dart:js_interop interface. That library
only statically allows Functions to be passed if they're
externalized, in which case we shouldn't tell users to wrap
the Function with allowInterop (which doesn't exist anyways in
dart:js_interop).
Change-Id: If6fdc706e80837ab2b698cca704ffd9f08aed28a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446184
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Note: Const locals are still off for VM aot and dart2js for the entry
points I've found in an attempt to retain the old behaviour there.
It might be better if those targets could remove such locals in a
whole-world analysis instead.
* Keep const locals by default (except as noted above). Update the
verifier to accept that. For the platforms this has increased the
size by at most 6584 bytes. With this the VM will pass in any const
locals as it does normal locals, but as the variable is never
captured it will never pass a const local defined in a method when
inside a local function in that method.
* Change the dart scope calculation(s) to return the found variables
instead of just the types of the found variables.
* When the incremental compilers expression compilation - via the dart
scope calculation - finds a const local that it wasn't told about, it
will pass it on as an extra variable that it knows about, allowing
for evaluating const locals in the case not covered by the first
bullet.
With luck this can in future CLs be extended to know about other
variables that we're not told about, allowing to give a message saying
something like
"yes, we know what 'foo' is, but you can't currently use it" as wanted
in for instance https://github.com/dart-lang/sdk/issues/60316 and
https://github.com/dart-lang/sdk/issues/53996.
Tested: Existing tests for existing functionality; new tests for the new
Change-Id: I1ec24350273e6f81574bb2888f6bf46e3b8b1b47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445461
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
The analyzer already has an enum with the same name, but a slightly
different declaration. (The analyzer's enum declares only severities
of `error`, `warning`, and `info`, whereas the CFE's enum also
declares severities of `context`, `ignored`, and `internalProblem`).
I'm currently embarking on an arc of work that I hope will eventually
culminate in unifying the analyzer and CFE diagnostic message
representations (and their severities) into a single set of
classes. Until that unification is complete, both representations will
have to co-exist in the `_fe_analyzer_shared` package. To reduce
confusion during that time period, I would like the classes to have
distinct names.
Since the analyzer's `Severity` enum is exposed through the analyzer
public API, analyzer clients may depend on the name. So it makes sense
to rename the CFE's `Severity` enum.
Tested: standard trybots
Change-Id: I95622950f49b1754267e441e4636e046045629bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442102
Reviewed-by: Liam Appelbe <liama@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The analyzer already has a class with the same name, but a slightly
different purpose. (The analyzer's class represents a single message
associated with a source location, whereas the CFE's class represents
a message along with related context messages).
I'm currently embarking on an arc of work that I hope will eventually
culminate in unifying the analyzer and CFE diagnostic message
representations into a single set of classes. Until that unification
is complete, both representations will have to co-exist in the
`_fe_analyzer_shared` package. To reduce confusion during that time
period, I would like the classes to have distinct names.
Since the analyzer's `DiagnosticMessage` class is exposed through the
analyzer public API, analyzer clients may depend on the name. So it
makes sense to rename the CFE's `DiagnosticMessage` class.
Tested: standard trybots
Change-Id: I6b6948fe9da18c7b6688333fa12ffeea8e81436f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441831
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This type argument was never used. Removing it should make it easier
to make changes to the front end error message logic (and associated
code generator), which I intend to do as part of a long term plan to
make the analyzer and front end error reporting systems more
consistent, and eventually merge them.
Change-Id: I994cd2a74c5fd77df192f6a1f2dde46ba8a31883
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442723
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Moves helpers from local functions and instance methods in the compiler
to static extensions on kernel nodes. These can be shared between the
old and new compilers.
Change-Id: Ifc2b5fe8945753823d7671171673c6c7add1e8cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439806
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
* Avoids retrieving the instance type in more cases. In static class
methods (including constructor tear offs)
`dart_rti.instanceType(this)` was being used as the base of the
environment binding. In these cases the result was the reified type
of the JavaScript function. This worked as long as the base type of
the binding is ignored, but it was not intuitive and had to fall
through all the other cases before settling on that result.
* Avoids parsing a recipe for the `dynamic` every time when we already
can have it available in our type table.
Compiled code examples:
Building the type `A<R, S>` from function type parameters `R` and `S`:
Now:
`T.dynamic()[_bind](R)[_bind](S)[_eval]("A<1,2>")`
Previously:
`dart_rti.instanceType(this)[_bind](R)[_bind](S)[_eval]("A<1,2>")`
Building the type `B<R>` from function type parameters `R`:
Now:
`R[_eval]("B<0>")`
Previously:
`dart_rti.instanceType(this)[_bind](R)[_eval]("B<N+1>")`
where N is the number of type arguments of the enclosing class.
``
Change-Id: I213666edd7c6427f0d42d958541e53a798e8877c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439460
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Update the last known good component after a recompile reject back to
the expected state before the recompile.
Adds tests for expression compilation after recompile accept and
recompile reject cases with `--target=dartdevc`. Similar to existing
tests for the VM.
Removes calls to `_generator.accept()` and
`component.computeCanonicalNames()` from `compileExpressionToJs()`.
These were added very early in the prototype implementation and it is no
longer clear why they would be needed.
Added some additional test cases for expression compilation involving
import resolution because the change that originally added the
`component.computeCanonicalNames()` call implies it was needed for that
reason. See: https://dart-review.googlesource.com/c/sdk/+/138010
TEST=pkg/frontend_server/test/frontend_server_test.dart,pkg/dev_compiler/test/expression_compiler/expression_compiler_test.dart
Change-Id: I9c04bd46e56b33dc654d00fb330de29c3c643a5b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434522
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The name has always been annoying because it did not add strong typing. And now there aren't variants of the VM platform to distinguish.
Leave a copy at the old name to not immediately break illegal uses.
TEST=ci
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,flutter-frontend-try,flutter-linux-try
Change-Id: Ie76fa7f16940aa1ba8d582eb5197f0ae55dc8938
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429828
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Under the hood, there is no difference between
`isSubtypeWhenUsingNullabilities` and
`isSubtypeWhenIgnoringNullabilities` by now. This CL makes the
corresponding renames and removals in the CFE and its clients.
TEST=existing
Change-Id: I22060c29834179c30ba62562aa254146b1d7530d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433480
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Refactors the hot reload test suite to support non-FE server based hot reload. Similar to DartPad it uses a DDC process running in '--persistent_worker' mode and sends bazel requests for each reload.
I call this "stateless" mode because the compilation process itself is not maintaining any state. The necessary metadata is passed from one compilation to the other via a delta dill. This differs from the "stateful" mode where the FE server persists a kernel AST in memory from one compilation to the next.
Disregarding the browsers there are effectively 3 run modes now:
- web stateful
- web stateless (new)
- vm stateful
One key difference between the "stateless" and "stateful" modes is the output format of the JS files. In stateful mode DDC emits a file per library being re-compiled. In stateless mode DDC is emitting a single file with all the libraries.
DartPad's workflow is slightly simpler than what's seen in the stateless mode here. It only supports editing a single library so we skip processing any metadata. To simulate this I've added the special 'main_only' which passes a single library for each reload generation. I've verified that this would fail if not for the change recently made to ddc_module_loader.js.
Change-Id: If05da6dbeded4dd20e9e6d9dfaed52151541a19b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434340
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Nicholas Shahan