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>
This is no longer necessary with the VM only supporting the latest
version and kernel (optionally) including a git-checksum to match up
VM and dills.
Change-Id: Ifccfd0d12333cd99258100cda30e1536cc230bc2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166024
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
DirectPropertyGet is a statically bound instance access used in the
VM mixin tranformation to encode fully resolved super access. The
access to `this.name` generated in `toString` of an enum is _not_
a statically bound instance access but just a regular instance access
whose runtime target happens to be known statically because the code
is generated. In JavaScript backend a statically bound instance access
requires a unique getter to avoid the dynamic lookup, and therefore,
though using DirectPropertyGet is an optimization
to the VM, it would be a regression to the JavaScript backends if
they didn't handle DirectPropertyGet as a PropertyGet.
This CL removes the misuse and thus enables JavaScript backends to
handle DirectPropertyGet with the intended semantics.
Change-Id: Ie41aefbf19e8c63244f10a1afda1ddbfdf7d3c19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/164085
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The method 'uriUsesLegacyLanguageVersion' is used for automagically
running opt-in libraries in strong mode. This was still using the sdk
version as bar for opting in to null safety.
Closes#43605
Change-Id: Ic9a1836e022f60106d2bcf9a6c3d50aa56966028
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165720
Auto-Submit: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Paul Berry