This was intended to capture the set of variables captured anywhere in
a given function, but it doesn't actually work that way, because we
use a single AssignedVariables instance for the entire file. But
that's no problem; we can just track variables captured within the
function using AssignedVariables.capturedInNode().
Change-Id: I2c39f40029203f275cf9b3284c6077de089b91fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120501
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In preparation for creating a clean implementable interface for various
builder classes. This is in turn a precursor for deprecating
Builder.target
Change-Id: I83910e84da149775f46c0be4b10f7694fadd0a7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119843
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Use interface ClassMember instead of Builder in ClassHierarchyBuilder.
This avoids the coupling between DelayedMember and Builder and is a
precursor to removing Builder.target.
Change-Id: Ie2067512051618a60fcb94b5aae7e7f3d8c02b15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119644
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The interpretation of the subtype check result depends on the mode. In partial
NNBD mode all type errors that wouldn't be errors in non-NNBD programs should
become warnings. In full NNBD mode all such errors are errors. This CL adds
the mode explicitly to the interface of the subtype check as a parameter.
Bug: http://dartbug.com/38673
Change-Id: I14bcdd260618530cfdd8189c01abba7469a16679
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119545
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Returns types on generic methods in generic extension that contained
type variables declared on the generic method were not substituted,
leaving these as unindexed type parameters during serialization.
Change-Id: I4f53005318ba2be014bfe6e92f4f6c93288f2a4f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118995
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
It is no longer necessary to explicitly "add" variables that are
subject to flow analysis. Unrecognized variables are now treated
simply as uninitialized. This simplifies analyzer error recovery by
ensuring that an attempt to use a variable before its declaration
doesn't lead to a crash.
Change-Id: I11e8afc3ffb93c864db4638a224ff782d11f5a6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119200
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
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>
Johnni Winther