This CL also includes the following changes:
- The .registerTags() method is added to the Case combinator.
- The actual canonical names' root is passed into the deserializer.
- Some text serialization failures are fixed and the corresponding
status entries in text_serialization.status removed.
Change-Id: I222dfa3fc348dddf83e0c6edb92f15d08b8e73e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143803
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
* Throw a specific error on mixed compilation mode; let the incremental
compiler ignore that error when trying to initialize (i.e. it doesn't
initialize from it, but it doesn't show any warning either).
* Allow some mixed mode stuff: Eventually the SDK should be in agnostic
mode, so we should allow mixing agnostic with non-agnostic.
Fixes#41493.
Change-Id: Idb33fb31afe6bbba6d74134cb722ca825751898b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143583
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This bit is required to support synthesized field used for the late
lowering. These fields should not be seen as part of the interface,
that is, classes that implement the class declaring the late field should
not be required to override these fields.
Closes#41436
Change-Id: I9a98322bdd1842b46bde34fff1176a7577672e0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142998
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
`isIgnorable` is the new way to determine whether a report from the
analyzer can be ignored. Codes with an ERROR severity are not ignorable,
and the new SecurityLintCode is not ignorable.
Change-Id: Ied72f1b61808eda088b947b8836e0cf1dfdd9850
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143331
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Adds support for pretty printing verbose annotations.
Adds support for force updating annotation texts useful for applying
the pretty printing to valid annotations.
Change-Id: I8fe9b6d2f8198bd5e160854053c8d964ef832a8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129710
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
When creating a library for expression evaluation we should copy
NNBD properties from the real library, otherwise VM may refuse
to load resulting kernel binary.
Change-Id: I594b718c74e516f998593cde55ea0cabaf3b4024
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142443
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
When it prints the important parts (here) is:
* Print (e.g.) "class Bar extends core::Object" --- it thus visits the
canonical name for "core::Object"
* Prints fields in "Bar" (and thus lazy loads more content).
* Prints constructors with stuff like "super dart.core::Object::•()".
With NNBD SDK this is what happens:
* Prints "core::Object" via *canonical name*.
* Lazy loads; this create a reference on "core::Object".
* Prints "core::Object" via *reference* -> this gives another name (core2).
On the second print it:
* Prints "core::Object" via *reference* (as it was already loaded)
-> this gives the previous "other name" (core2).
* Lazy loads
* Prints "core::Object" via *reference* -> this gives the previous
"another name" (core2).
The important part is, that when loading class Bar (in lazy loading
mode) it has lots of members --- e.g. "Bar::_identityHashCode" which is
a member signature. The name is private and thus has a Library
(dart:core) --- via reference. This creates a reference on the
canonical name for "dart:core".
With a non-NNBD sdk the same thing happens, but there member signatures
aren't there, so dart:core is never given a reference and it thus
continues to use the reference.
The "fix" here is to print the whole thing (and thus lazy load what's
needed) up front, before using the output for a comparison.
One might argue that the ast_to_text printer should be fixed instead,
but for now that's not done.
Fixes#41293.
Change-Id: I87bdfc6357196f52e560ec90de6f5ea3ff610b1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142026
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@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>
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>
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>
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>
Generalize `TypeAliasBuilder.unaliasDeclaration` such that it takes
an argument `typeArguments` and uses that to handle the case where
a type alias application ultimately expands to a type variable (e.g.,
with `typedef F<X> = X`, `F<int>` expands to `int`), and also to
emit a compile-time error in the case where such a type alias is
used to invoke a constructor or invoke/tear-off a static member.
Next step: Pass `List<UnresolvedType> typeArguments` from `handleSend`
to `finishSend` etc. to `BodyBuilder.buildConstructorInvocation`,
which seems to be a somewhat larger refactoring; needed in order to
make `generic_usage_class_test` pass. Some other fix is needed in
order to make `generic_usage_type_variable_test` pass.
Change-Id: Icd3593f03c6348c50b1ec3d7c9676f1bd7c56daf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141240
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Johnni Winther