The return value of the GraphBuilder visit methods should always be
the type of the AST node assuming it's used as an expression. When a
type name is used as an expression, its type is always a non-null
reference to the built-in type `Type`.
(Note: this wasn't causing any failures, but fixing it will allow me
to add stronger assertions in a follow-up CL.)
Change-Id: I62c72dcfc6c0f12f8d8a1a7de34a1d3f94c5e4f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105962
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This removes one location where ErrorToken processing is no longer needed
in the parser, and updates the analyzer parser tests to use scanString
rather than instantiating the scanner directly.
Change-Id: I399d771004af7f9fe25d19c1065fbfd425416edc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105901
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
* move names to Identifiers
* move resolution parts to front end strategy
* move codegen parts to backend strategy
* remove now unneeded methods from FrontendStrategy and BackendStrategy
Change-Id: I0675d56045dd212ad195177ecd23b27b0d849a80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105742
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
During constant evaluation, unused arguments to a const constructor are
thrown away after evaluation, since their values do not affect the
resulting instance constant. If such an unused argument ends up
unevaluated, any errors that would arise in the final evaluation are
not reported.
This CL adds space in the Kernel AST for saving these unevaluated
expressions so they can be checked during final constant evaluation.
Even though this is an incompatible change, no update is needed to the
VM code (except for the version bump), since the VM does not support
InstanceCreation nodes in the first place.
Change-Id: I4752562c1164efbba79eb018c15b07ed8354ce5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105761
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Includes changes to implicit covariance test.
To redescribe this, for some tear-off C<T>.f, the member type may be
contravariant if T is referenced by a parameter of C<T>.f (such as if it
is of type void Function(T)). This must be a runtime failure if C<T> is
a reference which has been covariantly upcast at runtime. For example,
List<Object>.add, where the list is at runtime an instance of List<int>,
results in a static type of void Function(Object), but a runtime type of
void Function(int), which is unsound.
We omit these checks, however, when it is trivially sound for all cases
Previously, this was the case for tearing off `List<Null>.add`. This is
no longer a valid test case for NNBD where the runtime type of that list
could actually be `List<Never>`.
Therefore the test has been changed to expect `List<Null>.add` to result
in a cast, and a new NNBD test case has been added to test `List<Never>`
cases don't get a cast.
Change-Id: I61d024a249e2c2a249ad5a8037cbe3d103e3ea8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104361
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This will simplify some situations where nullability migration would
otherwise have to visit the source code in a very careful order. For
example, when analyzing top level fields undergoing type inference, we
can simply create a node for the nullability of each top level field,
and then later use the "union" operation to hook up those nodes to the
nodes resulting from analyzing their initializers. Without the union
operation, we would have to be careful to visit the top level fields
in dependency order.
Change-Id: I3b07e1abccc5b1c9f1c7c9fa7b13fb6af60c07d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, they were static, which made them easier to access, but
made it difficult to track their edges (because we couldn't safely
mutate them, so we had to store their edges in special fields of
NullabilityGraph). Now that we're passing NullabilityGraph all over
the place anyhow, there's no benefit to making them static anymore.
Change-Id: Ia3e7d32ae479f40f505621e5d6df04060e39b1c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105723
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
New summary2 will unblock fixing long standing inference issues in
Analyzer.
We build it in addition to summary1, and will switch clients to summary2
incrementally. With this CL DDC will build summary2, but will not
consume it yet for analyzing code. This will be done in a separate CL.
This change was also tested in the internal repo, and does not cause
related build failures.
Change-Id: Ic2c635e45b514a2610e938129fa7527fd8d070b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105261
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes the problem when the flutter bots run multiple tests from the flutter tool e.g.,
flutter test first_widget_test.dart second_widget_test.dart
The first test causes the set of libraries, particularly Flutter's framework library, to be passed
to the transformer. The transformer needs the 'Widget' class located in Flutter's framework
library. The transformer on the first test works. Each subsequent test only the libraries not in
the prior test are passed, without the framework library, the transformer is unable to find the
'Widget' class and the widget transformer fails to run.
This fix allows the use of a nice speedup to hot-reloading Flutter applications when
--track-widget-creation is enabled and it allows us to enable --track-widget-creation by default,
for command line Flutter users.
This fixes issue https://github.com/dart-lang/sdk/issues/36640R=jacobr@google.com,askesc@google.com
Change-Id: I9a9c9dc69995122d0f7a7a3e1dfaebf57abb4afb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105661
Commit-Queue: Terry Lucas <terry@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Jacob Richman <jacobr@google.com>
Eventually it should be handled by Procedure.isRedirectingFactoryConstructor, but that is
currently broken for patch files.
It appears the VM has no patches of that kind, but dart2js does.
Change-Id: I0b64379f16089ad0d98ecd4df1ed9282ed6bc0e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98523
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
_Builder in source_gen uses code like this to check that the generated
file is expected in the library. While it is a questionable approach,
I don't feel that I have time to fix it, and remove the `uri` property
completely. So, we fix in in Analyzer with summary2.
`if (!library.parts.map((c) => c.uri).contains(part)) { ...fail... }`
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I983f29589cbb2613d5f896b87f6218c31a47afa9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105601
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Before this CL, whenever a dill library builder was asked to compute
the outline it would finalize its exports - even if it was already done.
This is not really a problem (it mostly puts stuff into maps --- doing
it again will just overwrite what's already there with the same thing
again), but when having many dill library builders, and asking them to
compute the outline again and again because we've added a few new ones
(e.g. via kernel worker) it adds up to a lot of wasted time.
This CL adds a boolean to the dill library builders to avoid re-doing
this already done work.
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
(and lots of dill loaded dependencies) goes from ~149 seconds to
~143 seconds.
Change-Id: I19cadbf64ff5e0ff117bad4df86c83832a1f28fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105243
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Dan Rubel