Pass variance data to field in TypeParameter through the listeners.
ast_to_text will print variances for classes and mixins if specified.
Avoids serialization/deserialization (impl in future CL).
Change-Id: I298537604823710f0d30001f4cb5f1e81530959f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118464
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
TL;DR: Use cases of 'legacy' constructor are covered by the 'omitted'
constructor.
The initial idea behind the removed constructor was to use it on all
types in opted-out libraries, as if the programmer had a way to specify
which type is legacy. That didn't prevent from building the 'omitted'
NullabilityBuilder into 'legacy' nullability sometimes. In some cases
we still had to use the 'omitted' constructor because we didn't have the
access to the library object yet, and then, then the
NullabilityBuilder.build method is invoked, and the library object is
passed to it, we build 'legacy' nullability.
Change-Id: I975fa93e23ee55e93db5f3e642a97ad6901b06c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118568
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The .buildType method and its implementations should receive builders as
arguments, not already built objects. The already built objects should
be passed to .buildTypeWithBuiltArguments instead. The absraction level
is prserved in this CL by passing in a NullabilityBuilder, not a
Nullability into .buildType.
Change-Id: I1dd87974e0081b82a5c6593f3e8a133d20563f6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118563
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Handles expressions like `Extension(c)?.foo`.
This CL also includes an update to SourceExtensionBuilder.build
addressing a comment in a previous CL.
Change-Id: I0ebcd95d16743c0aa6da22120182b2219fc30726
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118443
Reviewed-by: Jens Johansen <jensj@google.com>
With the experiment flag on, will properly parse the `in`/`out`/`inout`
keywords. Without it, will issue an error regarding the flag. First CL
for parsing, syntax support, no AST work yet.
Keywords only parse correctly for classes and mixins.
See test `variance_disabled_syntax_test.dart`.
Change-Id: I37d765804fa0752512abf52fa44456a173087ef0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117929
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
With something like
x2() {
y(z, {z}) {}
}
in a part, we create an error on the 2nd 'z'.
That error message gets the file uri of the body builder which is correct.
The context gets (for the 1st 'z') gets the file uri of the
FormalParameterBuilder which in turn got it from the "parent" which is the
library which is the "main library", i.e. not the "part library".
This causes - in the face of parts - one of two things:
1) It will point into the wrong file and the error message will be bad.
2) It tries to point into the wrong file, but the wrong file is not big
enough, and we thus get a crash.
This CL fixes it so the FormalParameterBuilder has the right uri.
Fixes https://github.com/dart-lang/sdk/issues/38523.
Bug: 38523
Change-Id: I303dbec2934ae930b8f2f2c9f63a4aa00db3a89c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118448
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Because we cache dills, it gives problems when loading the same library
from two different dills and starts "ping-ponging" between them.
See http://dartbug.com/38496 for details.
This solves the problem by removing any old dill from the cache,
that overlaps with what we're loading in now.
Bug: 38496
Change-Id: I61c2b3694d1d0d8fd5e9b62c4a03b6ac03ae4308
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118386
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously the errors were reported using the synthesized name, like
`Extension|method` instead of `method`.
+ Report errors on invalid uses of explicit extension application as
an expression or lvalue.
Change-Id: I6d85430be4ab3966ee94131b37aa365265c07eac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118383
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Currently Dart SDK has 2 platform dill files:
* vm_platform_strong.dill is used when compiling Dart sources (in kernel
service and various kernel compilers).
* vm_platform_strong_stripped.dill is used to build core snapshot,
so its contents is used for execution in the VM.
Before this change, if Dart SDK is built with bytecode, then both
vm_platform_strong.dill and vm_platform_strong_stripped.dill contain
bytecode and AST.
This change removes bytecode from vm_platform_strong.dill, and removes
AST from vm_platform_strong_stripped.dill.
Sizes:
Dart SDK is built without bytecode:
5861400 out/ReleaseX64/vm_platform_strong.dill
2819336 out/ReleaseX64/vm_platform_strong_stripped.dill
32105720 out/ReleaseX64/dart-sdk/bin/dart
Dart SDK is built with bytecode, before this change:
11146480 out/ReleaseX64/vm_platform_strong.dill
4846488 out/ReleaseX64/vm_platform_strong_stripped.dill
34219256 out/ReleaseX64/dart-sdk/bin/dart
Dart SDK is built with bytecode, after this change:
5861400 out/ReleaseX64/vm_platform_strong.dill
2027224 out/ReleaseX64/vm_platform_strong_stripped.dill
28382456 out/ReleaseX64/dart-sdk/bin/dart
Change-Id: Ia7c61a9bce1c95edfd3b2810a67c0964fb37377f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118371
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Kallen Tu