ExpressionCompiler crashes while detecting current scope
if there are any scopes in the library with valid fileOffset
and invalid fileEndOffset.
Make ExpressionCompiler more tolerant to incomplete offset
information by just skipping scopes where fileEndScope is not set.
Fixes: https://github.com/dart-lang/sdk/issues/41241
Change-Id: I357017be1cb641053f23144edd5b74f30a9240ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142080
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
This reverts commit 78435da54b.
Reason for revert: The mac builds failed due to clang not understanding the linker option on Mac. Will also investigate Ryan's question around interaction with profiler.
Original change's description:
> [vm] Add linker script to hide symbols from standalone embedder executables
>
> This is a safeguard to prevent users from depending on standalone
> executable internal symbols.
>
> This was already done in g3 in cl/304142297 for b/151696305.
>
> Change-Id: Ie01fc662eba7f8873530721394821b6c6c85e510
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142023
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,kustermann@google.com
Change-Id: I824fa99658612856df6cecc1533a1ea7ee87c54e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142024
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Derive whether legacy and nullable types are emitted based on the
provided sdk libraries and only enable the non-nullable experiment
when building the platform files.
The test matrix continues to enable the experiment temporarily
because test_runner currently doesn't support running with the
ReleaseX64NNBD configuration if it is not enabled in test.py
Change-Id: I7322906e928c68acab77087bcba76f06ef4bf983
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141850
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This is the "next step" mentioned in
https://dart-review.googlesource.com/c/sdk/+/141240.
`List<UnresolvedType> typeArguments` were dropped (and null was passed)
in several cases in `handleSend`, but they are needed in
BodyBuilder.buildConstructorInvocation in the case where the receiver
of the constructor invocation is a type alias.
This CL ensures that the `typeArguments` are passed when needed, and a
named parameter `isTypeArgumentsInForest` is passed in order to preserve
the information about whether or not they have been to the `forest`.
The CL also adjusts tests '{generic_,}usage_type_variable_*' to fit the
decision made in language issue 848 that a type alias cannot be used
for constructor invocations when it (directly or indirectly) denotes
a type variable.
Change-Id: I8d831457e35a7455f8fcfe461a10872c61555748
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141543
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
I have tried several attempts to make the test continue to work,
including:
* Running JIT pipeline with the special TD AOT optimization pass
* Running AOT pipeline, clear deopt ids and run in JIT
* Change only parts of compiler backend
None of the approaches are working really well, so we'll just not run
the code.
The vm/cc/IRTest_TypedDataAOT_FunctionalGetSet continues to check the
generated IR graph.
Closes https://github.com/dart-lang/sdk/issues/41148
Change-Id: I81c3f7900443eb5a5ed7b9641185b9b9d5c4debb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141245
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This is a safeguard to prevent users from depending on standalone
executable internal symbols.
This was already done in g3 in cl/304142297 for b/151696305.
Change-Id: Ie01fc662eba7f8873530721394821b6c6c85e510
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142023
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This handles (un)assigned state in try-statement that do not
complete normally. In this case we could create a variable model
for an unreachable state that would be both assigned and unassigned
leading to an assertion failure.
Closes#41284
Change-Id: Id4c7689bc7c614338af3542eb342c964696fca1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141981
Auto-Submit: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The following test began passing:
dartkp-strong-linux-release-x64:language/nnbd/syntax/required_modifier_dynamic_error_test was fixed (RuntimeError -> Pass)
Change-Id: Id31547734d081f9a5ef4cd1ecf084495eeb3a9d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141763
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Updates Mar 19, for better precision in tests (that is, catching
more bugs):
Added tests where `r.m(null).isEven` is used
to near-verify that the receiver `r` implements `A<int*>`:
With `A<int>` it's an error to pass `null`, and with `A<int?>`
it is an error to invoke `isEven`.
Added '1_error' test to detect that `r.m(null).isEven` is a
compile-time error in cases where the receiver has a different
member signature for `m`.
Added '3_error' test to detect that it is a compile-time error to assign
'D().a' to a specific type, for many `D`. This helps catching the
situation where the member signature of `a` is legacy: if that were
true then this test will fail because there is no error).
Change-Id: If6abafbadb51dcb04d13876b577d15c74bf47ccc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139817
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When compiling a big internal app with the NNBD SDK there's a big time
regression. This is a first "poor-mans fix" that "fixes" it via caching
which probably is not the best solution, but does the trick.
Without change
==============
Without NNBD platform:
$ out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart --target=dart2js --platform=out/ReleaseX64/dart2js_platform.dill -v bigapp.dart
[...]
0:00:14.238352: Built class hierarchy in 1663ms.
[...]
0:00:55.871356: Wrote component to bigapp.dart.dill in 5690ms.
With NNBD platform:
$ out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart --target=dart2js --platform=out/ReleaseX64NNBD/dart2js_platform.dill -v bigapp.dart
[...]
0:04:41.842548: Built class hierarchy in 268716ms.
[...]
0:05:22.120455: Wrote component to bigapp.dart.dill in 5407ms.
So: Big regression; it takes almost 4.5 minutes to built the class
hierarchy and almost as long extra to compile as a whole.
With change
===========
Without NNBD platform:
$ out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart --target=dart2js --platform=out/ReleaseX64/dart2js_platform.dill -v bigapp.dart
[...]
0:00:15.255893: Built class hierarchy in 2175ms.
[...]
0:00:55.203753: Wrote component to bigapp.dart.dill in 5306ms.
So: Without the NNBD platform there's basically no change.
With NNBD platform:
$ out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart --target=dart2js --platform=out/ReleaseX64NNBD/dart2js_platform.dill -v bigapp.dart
[...]
0:00:15.864901: Built class hierarchy in 2574ms.
[...]
0:00:55.640201: Wrote component to bigapp.dart.dill in 5363ms.
So: With the NNBD platform, the speedup is significant and there's basically no
change between using the NNBD platform or not.
Change-Id: I74993710a34f08f69421b03f2682ff8418af7599
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141982
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously, when handling an override such as:
abstract class A {
int/*?*/ f();
}
class C implements A {
f() => 0;
}
we would create a union edge between the implicit return type of C.f
and the explicit return type of A.f. This was a problem because
nullability information can propagate bidirectionally through union
edges, so it could result in types unnecessarily becoming nullable,
e.g.:
abstract class A {
int/*?*/ f();
}
abstract class B {
int f(); // Should not need to be made nullable
}
class C implements A, B {
f() => 0;
}
This CL fixes the problem by just making ordinary unidirectional edges
for overrides involving inferred types.
Change-Id: I63a5f1f640b5543fcf39304087592e984aa66694
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141853
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Migrated language/bool tests expect TypeError when null value is used
in a condition (which is still possible if static type of condition is
dynamic). This is right in NNBD strong mode, as implicit cast of null
to bool will fail with TypeError. However, in NNBD weak mode implicit
cast passes, and then AssertionError is thrown as before.
Before migration language_2/bool tests expected AssertionError.
This change forks the tests to behave differently in weak and strong
modes.
Change-Id: Iaba9e606bafe5740a998a60a74a6b54e38cac86b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141800
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
error_stack_trace2_test: As part of the late field spec, we no longer
have a special error for cyclic statics, so they just end up with stack
overflow errors, which don't have a stack trace.
list_..._test: Modify ListMixin<T> in NNBD libs so that addAll,
replaceRange, and insertAll work for non-nullable T.
Change-Id: I0f3f0c30f1aa45ea148eb5cdc954f024b7ba4777
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141252
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Alexander Markov