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>
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>
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>
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>
There was a crash in the logs.
_TypeError: type 'GenericFunctionTypeElementImpl' is not a subtype of type 'ClassElement'
at WrapInText.compute (wrap_in_text.dart:26 )
at FixProcessor._addFromProducers.compute (fix_internal.dart:4506 )
at FixProcessor._addFromProducers (fix_internal.dart:4520 )
at FixProcessor.compute (fix_internal.dart:762 )
at DartFixContributor.computeFixes (fix_internal.dart:82 )
R=brianwilkerson@google.com, pquitslund@google.com
Change-Id: I187b3348a212391cc6c64ab2c412653bd2319334
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141820
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
One can for instance run something like out/ReleaseX64/dart \
--enable-asserts pkg/front_end/test/parser_suite.dart \
-DupdateExpectations=true -DannotateLines=true
and have expect files look like this:
[...]
// Line 5: }
endBlockFunctionBody(1, {, })
endTopLevelMethod(void, null, })
// Line 6:
endTopLevelDeclaration()
endCompilationUnit(2, )
Change-Id: I3d98bbd24117a8f91823e739b5174d87a8c36fbe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141885
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When clicking on a region, store its offset & line in the URL via
`pushState`, so that on reload (after rerun migration or after apply
edit, or just in general) the context isn't lost.
Note that offset is not enough. Basically, every navigable element gets
a class `o$offset`, and if the page is loaded with some offset such
that no element with class `o$offset` exists, it falls back to line
number. And if there were edits mode before the region since reload,
there will only be an element `o$offset` if you are lucky.
Change-Id: Ic5fd83aceb4e8731348e70c039fec2ca2a6ab9e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141465
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Including the library name/uri in types and member names makes these
unreadable in most cases. This changes that default toStringInternal
to omit the library name/uri but supports a verbose mode that includes
the library name/uri for debugging the rare occasions where they matter.
Change-Id: I783e8bd0ac5d2f19c3051e8e7f226b240c8d1bc8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141546
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Anna Gringauze