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>
This CL updates the parser to parse extension declarations where
the extension name is omitted. For more details, see
https://github.com/dart-lang/language/pull/303/files#diff-9b84d2e3c88265bde2eb43544ddb757dR66
This change explicitly does not handle the case `extension on on on { … }`.
A subsequent CL should either make `on` a builtin
or add more lookahead in the parser to allow this edge case.
Change-Id: Ided821192770f88a51a3300fed8cb0fdef9eea3f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105900
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>
I'll build on this in future CLs to address more complex cases, where
the type is instantiated to a bound.
Fixes#37213.
Change-Id: I1e23c5599557ef17177483222f15b1a7985b9ca8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105726
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
It seems that this is necessary for Angular compiler.
R=brianwilkerson@google.com
Change-Id: Ib5c0501d8f900ec9ca358cb4f4b4be90004cce77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105720
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
So that we don't accidentally start to use them elsewhere in the
migration engine.
Change-Id: Iee290f9fc8761c952a2aadb1f4f6bb7bfe061a3f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105700
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>
+ use it in dart2js to simplify and clarify handle of local function nodes
Change-Id: I35da2dd8bd3baba6eff6ad631ebe63d572bae4d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105423
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This updates dartfix to display details about the analysis process
if the analysis server provides them.
Change-Id: I0b2a7e8267b92e1eefd1ce90aa53a85cc91c48d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105549
Commit-Queue: Dan Rubel <danrubel@google.com>
Auto-Submit: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
I still was not able to reproduce the issue, but I think this fixes it.
R=brianwilkerson@google.com
Change-Id: I209812bd2f2e8f0a5568ef14f7bfeaa4093c1341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105621
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
Previously we created artifical edges from a LUB node's components to
the LUB node; now the nullability propagation algorithm understands
how to propagate nullability downstream through LUB and substitution
nodes, so no artificial edges are needed.
Change-Id: Ib2fef14c3dcd58a013ad8e057fd55597a1deb4fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105402
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This paves the way for removing the transitional API altogether.
Change-Id: I95181b04173d3439d278f898ae3b5ec574108b32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105411
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
It wasn't detected by the "unused field" hint because there is another
field in the same file with the same name that *is* used
(NullabilityMigration._graph).
Change-Id: I955f30d010ddaa2d218f61daf32978d391182708
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105410
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
We need to make sure that it is set when we create FileState(s).
Change-Id: I68103902d0f4df659291e02dd7809b2140b9af72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105480
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This gives us more flexibility for how we want to publish and deploy
the tool. We now have the option, for example, of making a command
line app that invokes the tool and does not depend on analysis_server.
Note that some testing infrastructure had to be duplicated. I plan to
consolidate this infrastructure in follow-up CLs.
Change-Id: I046506bc2bb5c3e467e15885f198ee0632351ee9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105463
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is a temporary way to ensure the bots will fail on these test suites until
the test matrix provides the output directory. At that point, the .json files
will be used to track test failures and the exit code is no longer necessary
TBR=vsm@google.com
Change-Id: Ie96c3835760de02addc89f7ccbcb3ccb04c21940
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105405
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This addresses the most concerning problem in #37117
Change-Id: I38feb310023b066922a8049c5026a49572c3e399
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105461
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This allows the test runners to use snapshots instead of using the compilers
directly from source.
Change-Id: I70664a740bed8de647adb658bd521cd574aa685e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104385
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
For this to work properly, we first need the test infrastructure to have support
for the `--output-directory` flag (see base CL)
Change-Id: I75f788d19ad3b4e9523830250c4a1c9de8418cda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104400
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Closes#37153
Isolate.resolvePackageUri was the only API which had an implementation
across DDC and dart2js. The implementation in dart2js has been broken by
default since Dart 2.0.0 without a user implemented hook that is not
used on any public repo on github. Our current supported path for
invoking the compilers on projects disallows the import altogether on
the web and it is only usable with an older version of the
`build_web_compilers` package, or by invoking the compiler manually
outside of the build system. This CL does not break the ability to have
the import when invoking outside of the build system.
- Drop implementation for `Isolate.resolvePackageUri` from the dart2js
and DDC patch files.
- Drop all references to `defaultPackagesBase` since it is not used.
- Drop all tests under `isolate/browser` since we do not expect any
support on the web. Most of these tests would have already been
failing. Remove status file entries that refer to the deleted tests.
Change-Id: I4a19213b0946d835c00e9c107a714f3bc5672f86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105080
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
This reverts commit 0779751b82.
Reason for revert: Broke test unittest-asserts-release-win:pkg/analyzer/test/generated/resolver_test (see https://ci.chromium.org/p/dart/builders/ci.sandbox/analyzer-win-release/5691)
Original change's description:
> Fix implementation of isDartCore and isDartAsync.
>
> It's not sufficient to check the name of the library, since a
> user-provided library could always name itself `dart.core` or
> `dart.async`.
>
> Change-Id: Id99cfc1ec89c5941e16b556e3c4dd175875a673f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104580
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> Commit-Queue: Paul Berry <paulberry@google.com>
TBR=paulberry@google.com,brianwilkerson@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I7a27b46f4b2d1b3b43f9943933ec2a75b5a5b806
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105346
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The change in the CL prevents the widget transformer from introducing
compile-time errors.
Change-Id: Ib4a73eb13fb33397daeb5d17c613c42a1d1a6025
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105245
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Kernel mode only
Build with:
> dart bin/dartdevc.dart -k --compile-sdk dart:core --modules amd -o dart_sdk.js
For now, this doesn't support building only parts of the SDK - dart:core brings everything in.
Change-Id: I23cda3064408778dc93c9b3d4be757f1e99bae0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104811
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
The Dart2JSCompileAll test has not been working for a while due to
- issues with package config
- issues with getting the sources compiled with CFE after the switch to
kernel pipeline.
Revised this benchmark/test to instead load the kernel_service dill file and do a CompileAll of CFE.
Should fix
https://github.com/dart-lang/sdk/issues/36630https://github.com/dart-lang/sdk/issues/27369
Change-Id: I07f5c81fc6938d318b84fa9ea2fa033ec30a05e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103406
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This CL cleans up the displayed help text, better organizes and displays
the list of fixes that are or can be applied, and addresses
a comment in https://dart-review.googlesource.com/c/sdk/+/105002
Change-Id: I2e71001ae7eda61b3b01ce999cb9fdca968a9b93
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105322
Commit-Queue: Dan Rubel <danrubel@google.com>
Auto-Submit: Dan Rubel <danrubel@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Prevent windows from doing a path lookup for 'dart:core' which will
crash. All we need is a string source with a uri..
Change-Id: I742060633f3bd89323ad3e3f0f19ae80c1aedbae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104806
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Change-Id: I02b2ceba0bf545932e8e99c940bb2373d9eb75ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105320
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This removes this --list option from dartfix and instead displays
the list of fixes when the --help option is specified.
Partially addresses https://github.com/dart-lang/sdk/issues/36875
Change-Id: Ibd8b124c2c20a752f7e661672eac8aa2e4483b26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105002
Auto-Submit: Dan Rubel <danrubel@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
So, that when changes to code that don't affect APIs are made, we
can use already linked bundles, and fuse it with informative data to
create elements with actual offsets and comments.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: Ia0aa8af3c734b2cff497b49363064a26d601ebf1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105142
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Before this CL this code would crash fasta:
```
class A extends Function() {}
```
Now it produces a compile time error instead:
```
t.dart:1:7: Error: Can't use a function type as supertype.
class A extends Function() {}
^
```
(technically it already issued it, but crashed before doing so).
Bug: #36824
Change-Id: Iaeb9dc8390d4a9ab7b473848c3311f08a4dbba6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101283
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Suprisingly this doesn't seem to affect performance, but doing basically
the same thing in two different ways is suboptimal.
Change-Id: I1cc52bceb05a0af4d0e0d0574c3599c063cf42a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105242
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Prior to this CL, we would issue a warning whenever a CanonicalNameError
was encountered.
This is in principal a good thing, but because we currently have no way
to detect if the sdk we get is the one we expect
(by any other measure than when it issues a CanonicalNameError) we often
issue these warnings for no "real reason" whenever, for instance,
the flutter sdk changes.
This CL splits the CanonicalNameError in two such that errors with
references to the sdk ("dart:" libraries) issue CanonicalNameSdkError
instead, an we then handle that differently. Namely we silently ignore
the error (i.e. don't issue a warning) and just don't initialize from
dill.
This should remedy the situation and be strictly better than to always
swallow CanonicalNameErrors.
Bug: 36032
Change-Id: Idbae0b5ee5b9843a5dbeb49b3c65ae25f5962e36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105240
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
It seems that we don't really need to have the same elements for them
for resynthesizing element model and resolved AST.
R=brianwilkerson@google.com
Change-Id: I05efdf90671f596f2f8b85a3808eb2c4c87ea8c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105003
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
- Skeleton Rti type
- Skeleton test
- Add dependency on command-line flag to get dart:_rti into platform dill
Change-Id: Idf383269c66c9951e23fd70a45ce65c54a973586
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104921
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Also, correct source position for CheckStack instruction in the prologue of
a closure.
Change-Id: I175e5398296f17a1f67a223d45725206e65e0e8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105040
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Caused by a ternary operator with differently typed branches.
Change-Id: I5f9cfc28c274c125db0a999237f81dc3523896cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104240
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
+ emit a bit more progress info with -v
Change-Id: I60e44b2a383c8f55ef57c2a4cca98340baa66a01
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104001
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This method should return `null`, since it doesn't visit an expression.
Change-Id: I018241c0d2e9b9f00bfe293352cf2707551c81e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104881
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We need this to support existingImports filtering, because filtering
is done on suggestion basis, not on the whole suggestion set basic,
because of re-exports.
R=brianwilkerson@google.com
Change-Id: Id97cb122fa6e3c5c62e367098e1917eba997a76f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104808
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit bb6e558534.
I found a problem with --use-summary2 in DAS.
When we implement actual API signatures, changes in bodies
change offsets for nodes, but summary2 also includes offsets,
and they don't match. So, DAS crashes. I will need to rework
offsets and other @informative data storage, so its turns
out that we cannot pretend so use real SimpleIdentifier(s)
anymore.
R=brianwilkerson@google.com
Change-Id: I1193cc3f6fd25aea1c39531e8a685b60b347166e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104949
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I119c44b30a1d3c6fb0d725ddb546cd3dcb31dab1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104809
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Note, this has the effect of including all DDC Dart sources with the
shipped SDK: we ship everything under sdk/lib.
This should enable https://github.com/dart-lang/build/issues/2262
Change-Id: If66bc7c620034e7f2acf7d2c3e9524a408417681
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104383
Commit-Queue: Vijay Menon <vsm@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
For constant field initializers, compile the initializer expression
to Kernel, perform local type inference, and perform necessary
rewrites during outline construction. This will support constant
evaluation during separate compilation.
Change-Id: I65fe601595c04c45d586d0bac97c2ade6ab15a90
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104564
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
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 ~160 seconds to ~150 seconds.
Change-Id: I80afa10caacef5e14e569928a1d421bd3e8ab342
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104003
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
It's not sufficient to check the name of the library, since a
user-provided library could always name itself `dart.core` or
`dart.async`.
Change-Id: Id99cfc1ec89c5941e16b556e3c4dd175875a673f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104580
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
So that we can start dogfooding it.
I noticed that we logged too much data, so I reworked what we
log in LibraryContext.
Currently performance will be subpar, due to using content hash as
file's API signature. So, any change to a file, even in a method
body will cause the whole library cycle (and everything that depends
on it) invalidation. I will implement computing API signatures for
parsed unit (hopefully reusing something already existing) in a
following CL.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: Ifb77e29188484b6784edbaa6a6d5daca6800ef2a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104603
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is required because otherwise
Object() == null
requires the type signature of Object.operator==(Object o) to be
changed to Object.operator==(Object? o). Which I don't think is the
behavior we want.
Confirmation that this CL is correct has been sent to the language
team. I recommend we land, which will unblock my subtyping CL, and
roll back/readdress later if need be.
Change-Id: I498f9870e7128b2cac3012fff0cb1ab50fcc8df7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104344
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
