Lookup of the setter of an assignable static extension field loaded
from dill failed because the DillExtensionFieldBuilder didn't identify
itself as a field.
Change-Id: I379e0002ec8180b0ac1c5b1440bf9725a87e889e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168480
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
- make sure nested blocks scopes are visited
- make sure variable definitions do not leak beyond block scopes
- properly collect scopes for loops, if statements, constructors
- add calculation of fileEndOffsets for blocks
- save block file offsets to dill
- update binary format version
- change kernel readers and writers to read and write block offsets
- change vm readers to read and block offsets for new version
- add missing fileOffsets and fileEndOffsets on functions for
late fields
- add missing fileOffsets and fileEndOffsets on functions for
extensions
- add errors on failures to find scope
- find libraries for private fields correctly
- add more expression compilation tests
- add test to verify fileOffsets and fileEndOffsets are set for
SDK summary (will add full dill tests later)
Closes: https://github.com/dart-lang/sdk/issues/40278
Related: https://github.com/dart-lang/sdk/issues/34942
Change-Id: I5bc1bb645543045b689d8d61069ee77dc4ee9025
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167541
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Flow analysis was failing on our encoding of duplicate late variables.
We add an invalid expression as the initializer on duplicate variables
and flow analysis was seeing this as if the late variable had (declared)
initializer. Changed to use the `hasDeclaredInitializer` flag on
VariableDeclarationImpl to bypass flow analysis in the synthesized
initializer.
Closes#43689
Change-Id: I483caa3bbc3347eb547826e9615a40fe62b586d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167741
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Invalidations below the framework layer could lead to NPEs, since the framework class types will get
recreated. To ensure this doesn't happen, look them up each time.
Instead of checking the component for subtypes, use an isExtended API and the existing mixed in API to
get the same results. This should allow this check to work correctly with the new invalidation strategy.
Bug: https://github.com/dart-lang/sdk/issues/43760
Change-Id: I439c085540403e29083c74b2add642656b3fa0a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167441
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Fields might be lowered to getter/setter pairs from source to
AST. This CL makes members able to show this for correct computation
of exports and handles scope patch-up when the relation isn't 1-to-1
between source and dill builders.
Change-Id: I5e4a711cd985730d320e582c3bd9d36602030992
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167320
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
- use parameter types passed to IncrementalCompiler.compileExpression
for compilation of the synthetic function containing the expression
- updated expression compiler tests
Note: some expressions that previously compiled wouldn't now
Example:
** package:test/library.dart **
class TestLibraryClass {
final int field;
final int _field;
TestLibraryClass(this.field, this._field);
}
** main.dart **
import 'package:test/library.dart';
void main() {
var instance = TestLibraryClass(1, 2);
print('$instance'); // Breakpoint here
}
Expression:
`instance._field`
Previously, the incremental compiler would compile the expression
to kernel due to the type of instance being Dynamic. That compilation
result made it impossible for dartdevc to generate correct code due
to missing type information.
Now, the compilation will fail with "Getter isn't defined"
error. To properly evaluate private fields now, we would need
the CFE to support a special mode for expression compilation
where private fields from other libraries are allowed.
Closes: https://github.com/dart-lang/sdk/issues/43469
Change-Id: Id8015c5e334115a82049fb2d1725db54dd3ea3dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166925
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
This CL stops trying to evaluate unevaluated constants if there's
(still) no environment, something that would happen before, e.g. if
there was something like this:
```
const original = String.fromEnvironment("original");
const copy1 = original;
const copy2 = copy1;
const copy3 = copy2;
const copy4 = copy3;
const copy5 = copy4;
```
Note that unevaluated constants only comes into play when there is
no environment.
Compiling a big internal app with dart2js takes the actual contant
evaluation part down from 8 point something seconds to 3 point
something seconds (-4662.67 ms +/- 537.29 ms, -54.4428% +/- 6.27357%)
and wall clock time (as reported by `/usr/bin/time -v`) down with
~9 seconds on the 8+ minutes run (-9.23 s +/- 6.70067 s,
-1.77065% +/- 1.28543%).
Maximum ram usage (`Maximum resident set size (kbytes)` reported by
`/usr/bin/time -v`) is down 700+ MB (-792367 +/- 364776,
-4.86424% +/- 2.23931%)
Change-Id: I1e1940a9e53de34cff2bcbd8eb938fdb23a22c83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166851
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
It turns out we didn't have enough id test coverage to tell that we
were passing the wrong value for `conditional_end`'s
`conditionalExpression` argument.
This change fixes the call site and adds an id test that would have
caught the bug.
Change-Id: Ie99b1b7045e757ee78d72fcb435222fd27d680d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166307
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change compiles opt-out libraries with opt-out semantics even when
sound null safety was requested. The compile-time error that libraries
cannot opt out with sound null safety is still produces but spurious errors
from interpreting opt-out as opt-in are avoided.
This also aligns the compilation of from-source with from-dill for the
case of opt-out libraries in face of sound null safety.
Closes#43327
Change-Id: I19d659219b7c7b357d15fc5f1ca4415fe1fc4592
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166243
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
TL;DR on the below: On a big internal app, this makes the constant
evaluator ~17% faster and use less ram.
Details:
Detauls for 5 runs before this CL and with this CL when compiling a big
internal app with dart2js (stopping at around "stopAfterClosedWorld"
with instrumented code available as patch-set #1):
Original:
Spend 9829 ms in ConstantEvaluator.
Spend 9935 ms in ConstantEvaluator.
Spend 9769 ms in ConstantEvaluator.
Spend 9725 ms in ConstantEvaluator.
Spend 9915 ms in ConstantEvaluator.
With this CL:
Spend 8110 ms in ConstantEvaluator.
Spend 8080 ms in ConstantEvaluator.
Spend 8183 ms in ConstantEvaluator.
Spend 8174 ms in ConstantEvaluator.
Spend 8155 ms in ConstantEvaluator.
Difference at 95.0% confidence
-1694.2 +/- 103.924
-17.2269% +/- 1.05672%
(Student's t, pooled s = 71.2569)
Original:
Maximum resident set size (kbytes): 13164908
Maximum resident set size (kbytes): 13179968
Maximum resident set size (kbytes): 13226748
Maximum resident set size (kbytes): 13296908
Maximum resident set size (kbytes): 13220740
With this CL:
Maximum resident set size (kbytes): 13006996
Maximum resident set size (kbytes): 13006720
Maximum resident set size (kbytes): 13020884
Maximum resident set size (kbytes): 13018172
Maximum resident set size (kbytes): 13160120
Difference at 95.0% confidence
-175276 +/- 86297.8
-1.32605% +/- 0.652888%
(Student's t, pooled s = 59171.2)
Original:
Minor (reclaiming a frame) page faults: 5720311
Minor (reclaiming a frame) page faults: 5688423
Minor (reclaiming a frame) page faults: 5693923
Minor (reclaiming a frame) page faults: 5699729
Minor (reclaiming a frame) page faults: 5650061
With this CL:
Minor (reclaiming a frame) page faults: 5612492
Minor (reclaiming a frame) page faults: 5603543
Minor (reclaiming a frame) page faults: 5600394
Minor (reclaiming a frame) page faults: 5628675
Minor (reclaiming a frame) page faults: 5621994
Difference at 95.0% confidence
-77069.8 +/- 29166.7
-1.35436% +/- 0.512552%
(Student's t, pooled s = 19998.5)
Said another way, we have some confidence that this change decrease the
runtime of the constant evaluator with ~17% on this application.
Similar we have some confidence that this change decrease the memory
usage with ~1.3% overall for dart2js (note though, again, stopping
early), or something like ~170MB less memory in this case.
(And having a similar percetage less minor page faults).
Change-Id: Ib269ad50f705b967e0e60e88fdcbfd9b050b3a24
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166105
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The previous implementation of type promotion in the CFE was unsound,
didn't follow the spec, and contained a lot of unnecessary logic
related to experiments that eventually led to flow analysis. This
change updates type promotion to be nearly spec compliant and removes
most of the unnecessary logic.
The lack of spec compliance went (astonishingly) unnoticed for over
three years, probably mostly due to the fact that for the most part it
promoted more eagerly than it should; as a result, any code that was
erroneously accepted by the CFE was rejected by the analyzer.
Unfortunately, in at least one case the erroneous promotion led to
incorrect VM behavior (issue #43640).
There's one aspect in which the CFE implementation is still not spec
compliant. The spec says that when analyzing an expression `e1 &&
e2`, if `e2` shows that a variable `v` has type `T`, but `e1` assigns
to `v`, then promotion does not occur. This turns out to be difficult
to model in the existing architecture, since much of the type
promotion logic happens during parsing, and any assignments that occur
in `e1` are parsed prior to figuring out that a logical and is in
progress. Fortunately, this is a rare circumstance, and allowing type
promotion in this situation is sound, so it should not lead to
incorrect VM behavior. Considering how long the other incorrect logic
(which was much more severe) went unnoticed, it seems unlikely that it
will cause problems for users.
Bug: https://github.com/dart-lang/sdk/issues/43640
Change-Id: If97293733e64e286780de5079a703717b8f6f142
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166040
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When the incremental compiler tries to initialize from a previous dill
it loads it and performs some tests. If any of this fails, in some
cases we want to swallow the error, ignore it, and not initialize from
the dill - whereas in others (unanticipated) cases we want to give a
warning.
This CL adds the InvalidKernelSdkVersionError error to the list of
anticipated errors that we silently ignore as we don't want to give
warnings whenever people upgrade the sdk.
Change-Id: Ib9e701fb61fa78690b024192054e28f4cca51717
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166060
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Johnni Winther