Long ago the compiler had logic for reading sources via an http
connection. This is not a supported use case and there is no need to
keep this around anymore.
Change-Id: Ic59c154def264a52d9310133f76b153c9972899c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251701
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The current [StringCanonicalizer] implementation has some issues:
* It hangs on to large [Uint8List]/[String] objects in it's cache
=> This requires users (such as analyzer) to clear the cache
frequently
* Has api that works on dynamic input (which is assumed to be String
or List<int> / Uint8List)
=> Call sites have typing information we loose when doing the call
* It uses dynamic [] calls to compare input bytes with cached bytes /
input strings with cached strings
=> Dynamic calls come with overhead
=> Will cause substring generation for every character comparison
=> Will compare bytes with strings (which doesn't make sense)
To address these issues we
* Use the canonicalized [String] to compare against instead of the
(much larger) source strings, thereby no longer hanging on to large
strings in the canonicalizer cache (it's still an issue with
[Uint8List]s though)
* Make seperate API for canonicalization of strings, sub-strings or
sub-utf8-bytes and use it from the token implementation.
* For canonicalization of strings use String.== (instead of
char-by-char comparison)
* For canonicalization of sub-strings use String.charCodeAt instead of
[] (which creates substrings)
* Seperate out cache node entries into two classes and reduce memory
consumption of the nodes that represent strings by 16 bytes (it
does an additional `is` check on lookups in the cache, but that is
better than paying for dynamic calls on the payload - which
causes the compiler to do implicit checks)
=> This CL reduces RAM consumption and makes CFE scan/scan_bytes benchmarks a little faster.
TEST=ci
Change-Id: I157c298d26d25ac5da82c32eedfa270a590156f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255121
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This script does the same job as `generate_resources.dart`, but it
doesn't search the filesystem for the input files to use, nor invoke
the compiler to create the `migration.js` file. Instead, it simply
accepts a list of input files on the command line, and outputs their
contents in an appropriate form to be stored in `resources.g.dart`.
This script will allow us to integrate more cleanly with the internal
build system.
Change-Id: I4b5445d1f5fd7eccbb5fb36f6ee4fa97d2cea87e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254421
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For large applications only ~60% of these objects are used. This defers their deserializtion until they're accessed in the codegen member map.
In local testing on large applications this saved ~200MB of memory usage in the linker phase.
Change-Id: I8ff87803fc23ef2d3f954646687e3fc67b68a4f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254600
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The CFE itself uses [Utf8BytesScanner] in it's normal operation. The
analyzer instead uses [StringScanner].
The performance script used today only measures scanning performance
based on [StringScanner].
=> This CL adds a `scan_bytes` subcommand that will measure scanner
performance based on bytes (the CFE default mode).
The performance script discovers the files to scan for the benchmark by
using the analyzer to transitively scan/parse files and looking at the
imports. Doing so will - as a side effect- fill
[StringCanonicalizer] with values.
=> This CL cleans the [StringCanonicalizer] cache before doing the
actual benchmarking.
TEST=ci
Change-Id: I996efe6b3551983df19ed5aad4fc4220c07336cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255120
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The analyzer wraps various functionality in logging calls like
await logger.runAsync('Prepare linked bundles', () async {
...
});
Doing so will cause time being measured and begin/end messages to be
written to a log. Those strings accumulate in a `StringBuffer` that
is never accessed.
For example running analyzer on a big app like flutter can cause
thousands of "--- Prepare linked bundles in 0 ms. " strings to be
generated and hanged on to.
This CL makes us no longer generate such strings - only if the
creator of a context supplies a [PerformanceLog] explicitly (in which case
it is responsible for draining the messages written to it).
This reduces memory consumption when analyzing flutter by around 3 MB.
TEST=ci
Change-Id: I4979a964f13c63bd2a3cccef97fb702431731139
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254925
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Some instances of analyzer have a heap of 600 MB, containing 400k
StringToken/StringTokenImpl.
This CL combines two existing fields which will shrink those objects
by 16 bytes, which saves 6 MB.
We densly number all token & keyword types so they can be looked up in
an array.
TEST=ci
Change-Id: I8431db243d55a316e7a72678844d031356c40e79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Changes `FfiNative` instance methods on `NativeFieldWrapperClass`es
that have `Pointer<Void>` conversion to check for `nullptr`.
If the native field has `0`/`nullptr` a `StateError` is thrown:
"Bad state: Native field is nullptr."
This only makes sense if the first native field is used to point to
the C++ object corresponding to the Dart object. As far as we know
all current use cases do so.
TEST=pkg/vm/testcases/transformations/ffi/ffinative.dart.expect
TEST=tests/ffi/vmspecific_ffi_native_test.dart
Closes: https://github.com/dart-lang/sdk/issues/49620
Change-Id: I92f760c33d391476010722358f9713fa4491ab61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254200
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Unfortunately my idea about checking for specific `DartType` subtype,
and only then asking for the element is too punitive. It almost
works in google3, but the amount and the kind of changes I had to
do make me realize that we should keep `get elementX` in `DartType`.
I guess this is the same as we had in AST when `get constructors`
does not make sense for mixins (?), but works for classes and enums,
and it is easier to pull it into the superclass.
Change-Id: Ibc4fac0b95d63748fa65de96d29300f477fdfc76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254482
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This change breaks flow_analysis.dart into the following libraries:
- assigned_variables.dart (for the AssignedVariables class and related
code)
- promotion_key_store.dart (for the PromotionKeyStore class)
- type_operations.dart (for the TypeOperations mixin and related code)
- flow_analysis.dart (for the rest of flow analysis)
And it breaks mini_ast.dart into the following libraries:
- flow_analysis_mini_ast.dart (functionality specifically concerned
with testing flow analysis)
- mini_ast.dart (functionality not specifically related to flow
analysis)
This is in preparation for trying to share some more type inference
behaviors between the analyzer and CFE.
Note that although the diff is big, the only changes in this CL are
moving code from one place to another, renaming some class members
from private to public, and updating imports.
Change-Id: I71768f03b1e75ed754c7b7af39f6cf7f03c4fe44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254462
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The library wasn't taken into account when handling computing class
members in the K/J-model and not handled correctly when computing
applicable selectors. This made dart2js unable to handle members with
a name private to a different library than the enclosing library.
Fixes#33732Fixes#49226
Change-Id: I5ba143d87662bbd42e0ff02355054e4a937be8f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252665
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The command name is a bit unfortunate in that it isn't very readable for
debugging purposes, but it has the advantage that there isn't any
opportunity for it to get out of sync. That might be the wrong thing to
optimize for. Let me know what you think.
Change-Id: Iec5c2ad9703f51c7702d4d5094f0548b48fbaafd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254321
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
* Move many identifiers from snake_case or SCREAMING_SNAKE_CASE to
camelCase. I think I restricted the changes to private API.
* Add an ignore in generated files for constant_identifier_names;
we often just mirror names found in YAML files or whatever, where
things are not necessarily named according to Effective Dart
standards.
* Avoid some implementation imports which I think were accidental.
* Use single quotes in some more places.
Bug: https://github.com/dart-lang/sdk/issues/48784
Change-Id: I439fe50cb9f8f8f5e9c74ce594aea15e394ee7da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This change splits the `Harness` class into a base class, `Harness`,
which in principle can be used for testing type inference logic in
general, and a derived class `FlowAnalysisTestHarness`, which is
specialized for flow analysis tests.
This is in preparation for trying to share some more type inference
behaviors between the analyzer and CFE.
Change-Id: Ic56b8dd8748065ca59e246e0d804946cc69203c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This involves changing the target expression which must be null-checked
or awaited. When we detect the FutureOr and the await expression, we
instead null-check the await expression.
Fixes#44041
Change-Id: I08cf03f6975e2e70d5c87ebda92e9538de19e02e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253863
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Jens Johansen