This CL fixes the wrong message, so - when in the process of fixing
the package nnbd settings - one gets the correct message, mentioning the
right packages and no longer mentioning the fixed ones.
Change-Id: Ied26094055e56b44dfdd2e942b98eb9e1e7968fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170423
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This fixes the issue of the error not going away, but can (see added
test) give a wrong error message when in the process of fixing the issues.
A follow-up CL will (try to) correct the wrong error message.
Change-Id: I3547fe5fb5cfd179897996029a00a4995a967e54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170422
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL adds predefined constructors to LateInitializationErrorImpl that
only take the name of the late field/variable as argument. This can reduce
the size of the generated code for ddc/dart2js size because the long
message isn't repeated at all call sites.
In response to #43995
Change-Id: Ie276dd1455feab1655da3a503856da425b20f04f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169883
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Most of the time one already knows at the call site if it's a Field,
a Procedure etc --- so use that instead.
For now I'll leave the corresponding getters that are basically
documented as "don't use" ("[...] for convenience, not efficiency.
Consider manually iterating the members [...]").
Change-Id: Ib732759432c62963e6645f85f6df301c4281df9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168826
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
* When initializing from a dill in the incremental compiler check that
the nnbd mode matches what we're asked to compile.
If they don't, silently do not initialize from the file.
* When serializing and deserializing, assert that the individual
libraries match the component compilation mode.
* When appending dill libraries in the CFE, assert that they match
what we're asked to compile.
* Remove NonNullableByDefaultCompiledMode.Disabled -- it's not a thing
anyway.
https://github.com/flutter/flutter/issues/68901
Change-Id: I2e68f17cb3a065c4352e4db7c8aee3c13747f23a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169080
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reproduces the weirdness seen in
https://github.com/flutter/flutter/issues/66122#issuecomment-714799890
In flutter it furthermore makes the compiled javascript go into a stack
overflow.
Notice how I've also had to introduce the option of disabling the
class ClassHierarchyTest (as it fails) to get both expect files so we
can see the differences, e.g. the introduction of
```
forwarding-stub set _widget(self2::HotReloadIssue* _) → void
return super.{fra::State::_widget} = _;
```
in `_HotReloadIssueState extends self2::__HotReloadIssueState&State&AfterLayoutMixin`.
Note that this CL doesn't fix anything.
Change-Id: Ieed6c4a3f36b94ddacc388fb2683b30e88f7d2ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168945
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Even when non-nullable is enabled by default, enabling the experiment
explicitly should result in the experiment release version (and not
the experiment enabled version) to be used for opting in.
For this change, the semantics of parseExperimentalFlags was change
to _not_ normalize the flags to a full mapping including default values.
For this reason all uses of such maps are renamed to
'explicitExperimentalFlags'.
Closes#43879
Change-Id: I0d0262e68ec1403549abcfd305ae3a4404fe93e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168654
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Previously, if editing messages.yaml and making a mistake one could
end up with empty "codes_generated.dart" and
"fasta_codes_cfe_generated.dart" meaning that nothing could compile
before doing a `git checkout <file>` on it.
Now instead generate-messages will just not do that.
Change-Id: I072d805772201af218609e7e45e5a6a2316de593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168648
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reverts commit 87d3e03bf8.
Reason for revert: Breaks internal builds (http://b/171258924)
Revert "[cfe] Use CombinedMemberSignature to create noSuchMethod forwarders"
This reverts commit 13b7a83d57.
Reason for revert: Depends on a commit that breaks internal builds
(http://b/171258924)
Revert "[cfe] Use CombinedMemberSignature for creating simple legacy member signatures"
This reverts commit 170f05f91b.
Reason for revert: Depends on a commit that breaks internal builds
(http://b/171258924)
Revert "[cfe] Use origin location for member signatures"
This reverts commit 354dcf4386.
Reason for revert: Depends on a commit that breaks internal builds
(http://b/171258924)
Change-Id: I51f524949f259351336a77f43847bf1d0d11f104
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168487
Reviewed-by: David Morgan <davidmorgan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Michal Terepeta <michalt@google.com>
This changes the reported failure from Crash to something more specific
to the encounter error, like ExpectationFileMismatch. Validation errors
for the .yaml file still produce Crash, and so does a couple of the
checks on Component integrity that were also used outside
incremental_load_from_dill_suite.dart
Change-Id: I48aa8cb25198d24e986b0f354db2b370dc9b8ac8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167565
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@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>
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>
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>
Johnni Winther