This change:
* adds the `--use-old-rti` flag to revert to the old behavior
* enables the new behavior by default
* changes the -rti- builders to run the old rti instead of the new rti
* documents the change in CHANGELOG.md
I've kept around the logic as `useNewRti` to avoid swapping all the conditions
in the compiler.
Change-Id: I773ac33b658cb60f72e0b6beef83375abec31bad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127492
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
So, it is not separated into ElementResolver and StatisTypeAnalyzer.
Change-Id: I413a71b703ab93304760e1f912c3d55585411397
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130132
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
When inserting Unbox instructions in SelectRepresentations pass, their
speculative mode depends on the instruction which uses corresponding
value. Phi instructions were using default kGuardInputs mode, which may
cause insertion of speculative Unbox instructions in AOT mode.
Such Unbox instructions may need deoptimization if type of an argument
changes during optimizations. Generating code for such Unbox
instructions causes assertion failure (in debug mode), or crash in
release mode.
The fix is to change speculative mode of Phi instructions in AOT, so
they won't cause speculative Unbox instructions.
Fixes https://github.com/dart-lang/sdk/issues/39747
Change-Id: Ic9c9957875fd775fe1c02f3666829f26dad64937
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130063
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
If OSR happens while calculating an argument of string interpolation,
array of arguments may be Phi and not CreateArray instruction.
In this case, canonicalization of StringInterpolate should gracefully
return instead of crashing. Such OSR may happen due to control flow
collections.
Fixes https://github.com/dart-lang/sdk/issues/39905
Change-Id: Ibf35a0f0ebb20d5a44102f7ddfd4e91925d7c6ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129900
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
I want to extract invocation inference into a separate helper, and
perform MethodInvocation resolution as a single step inside
MethodInvocationResolver. So, I want to set `Expression.staticType`
in several places. Using special subclass of StaticTypeAnalyzer does
not fit this intention.
I think `is` check is JIT optimizable well, and during analysis
we will have just one type of ElementTypeProvider.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: Ie718db35ac9426b35b538b92a2e2177828ae7ad8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130120
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
- Migrated test now expects `null is Object` to be false.
- Added expectations for `is! Object`.
Change-Id: I99c5dc76d2ccfa5a9fd853b7745b58edfff07085
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129309
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
The pc-relative calls were recorded with pc-offsets pointing to the start of the
call instruction, where as code-based calls were recorded with
pc-offsets pointing to the next instruction (i.e. return address).
This is inconsistent and caused us to hit an assert in
`Code::set_static_calls_target_table`. The assert was benign, but it is
good to maintain the uniqueness guarantee in the static calls table, so
we'll unify the encoding to use offsets to the instruction after the
call in both cases.
Closes https://github.com/dart-lang/sdk/issues/39811
Change-Id: Id0305befd78f09ed0b0e100f39641bca9e764442
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129717
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
I think we don't need it anymore.
Change-Id: I50b9cc4c0bd3693a7172a2e71cd24096708fd0db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130122
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Add support for generating annotations from actual data using
option -g
Change-Id: I88d9cdb62a38d579234b15097c9e9bb3d81ebe8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129708
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Entry points json files were replaced with pragma annotations a while
ago. This change removes these unused files.
Change-Id: Ib7d80b79f1afb63a05aca9a25e8ec6fc9ba72941
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130040
Commit-Queue: Samir Jindel <sjindel@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
The resolution-world-builder and impact transformer were holding onto a
class-hierarchy-builder in dart2js, which uses a lot of space.
On a some artificial sample apps with thousands of classes this
reduces the overall memory capacity by 25%. On a large internal app
this reduced the overall memory capacity from 13G to 11G.
Change-Id: I5d0d40764649364f2cd2411ef1346812beb411c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129544
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change does not enable the lint yet because there are many more violations
in the test and tool directories. I'm going to clean those up in a separate
change.
Change-Id: I8a7f9a9004d329db5ba34030cc8aa8e20d07f3ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130012
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Change signature of Loader::InitForSnapshot to return an error and check
for this error when initializing an isolate. This should fix the flaky
crashes reported in https://github.com/dart-lang/sdk/issues/39950
Bug:39950
Change-Id: I564b2f8f924378c156f5bb22238a760be187f8b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130041
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
The VM does not include image pages in its usual accounting of heap usage and capacity because they are immortal and don't contribute to marking or sweeping work. The heap snapshot does include objects on these pages, so it should include the pages in its notion of usage and capacity, otherwise the heap-snapshot can effectively claim it has more usage than capacity.
Fixes negative fragmentation reported by the heap snapshot page.
Change-Id: Ib9f3c395ee5a6e51ee9b4c9a834843851426910d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128565
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
I noticed that assist_internal and fix_internal have 3500+ and 5000+
lines, and base_processor seems doomed to repeat their fate. If we
could keep separate assists and fixes in separate classes and libraries,
we could isolate their specific machinary of helper classes and methods.
And maybe even improve code with time.
This CL is a proposal for a way to do this.
We share CorrectionBuilderContext across multiple producers, so overhead
is small - only creating producer instances and setting the context.
I considered separating assists and fixes into corresponding directories,
but when we have shared builders, we would need to put builders into
yet another directory, and have three libraries that are named
similarly - xyz_builder.dart, xyz_assist.dart, xyz_fix.dart... Not nice.
So, hopefully we don't have accidential name collisions.
R=brianwilkerson@google.com, pquitslund@google.com
Change-Id: Iacf0b27a40227645f249e69921f2b8d9bfe1d5ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129820
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Fixes#39074
DDC emits Dart code that can usually be called with the same semantics
as JS there is no guarantee that a function passed to JS and then
invoked successfully was wrapped with `allowInterop`. The wrapping is
always required in Dart2JS. To make DDC more strict, add interceptors
that check for the usage of `allowInterop`.
Whenever a JS interop function or setter is passed an argument which is
statically typed as a Function, but not wrapped with `allowInterop` at
the call site, wrap it with `assertInterop` which will check the
argument at call time and fail with a clear error if it was not wrapped.
Whenever a JS interop function is torn off, either at the top level or
from an instance, wrap it with a function that will also inject these
checks at runtime.
There are still holes where we can't catch the mistake:
- An argument which is statically dynamic and a Function at runtime
won't be caught.
- A Function which is stored in a collection won't be caught.
- A JS interop definition where a getter returns a Function which takes
a Function as an argument is not checked.
- A dynamic call through to javascript is not checked.
Changes:
- Refactor `_isJsLibrary` and add `isJsMember`, and `isAllowInterop`
utilities to determine what needs wrapping.
- Update `assertInterop` to give a more clear error when it fails, and
to ignore non function arguments.
- Add `tearoffInterop` to wrap a function an ensure that any function
typed arguments are wrapped.
- Inject `assertInterop` around Function arguments passed to JS methods.
- Inject `assertInterop` around Function arguments passed to static or
instance JS setters.
- Inject a runtime wrapper around static or instance Function tearoffs.
- Add a test covering all flavors of checks that are supported.
- Change the interop expando to an `Expando<dynamic>` in the NNBD SDK to work
around a stricter type check. https://github.com/dart-lang/sdk/issues/39971
Potential improvements:
If the `tearoffInterop` turns out to be too heavy, we could loosen it so
that we only wrap methods if any of their argument types are statically
declared to be a Function.
Change-Id: Ibc92df5b54e1a041b4102a07b8398b774b6bd1d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128462
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This change hides InstanceCallInstr inside PolymorphicInstanceCallInstr
and makes sure that PolymorphicInstanceCallInstr owns its arguments
(which would become critical once call arguments become instruction
inputs).
Also, PolymorphicInstanceCallInstr now extends TemplateDartCall which
makes it possible to avoid duplication of methods related to all calls.
Issue: https://github.com/dart-lang/sdk/issues/39788
Change-Id: Ie3d4ff46a8e99a0988ba88a88ca9a60be8503ce0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129307
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
