The AST-to-IR conversion stage now handles the `AdjacentStrings` and
`StringInterpolation` AST nodes. This required adding the `concat`
instruction.
Although this support is not strictly necessary for the
proof-of-concept of wolf analysis, the presence of the `concat`
instruction will make testing of some later analysis stages easier,
notably SSA analysis, since it is a non-trivial operation that
produces a fresh value from one or more previous values.
Change-Id: I0915e0413db51e4c67617f61d8facc4e84909a7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339640
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/54038
The main feature is a small expansion to what is allowed in the `flutter / assets` field. We used to enforce that the `assets` field is a list, and that each value is a string. Now we enforce that:
* the `assets` field is a list
* an asset is either a string, or
* an asset is a map, with at least a 'path' key, with a string value.
This requires deprecating the `ASSET_NOT_STRING` code, and introducing
three others:
* ASSET_MISSING_PATH
* ASSET_NOT_STRING_OR_MAP
* ASSET_PATH_NOT_STRING
In addition I cleaned up a UX issue: Several codes referenced an 'asset' key, but it should be 'assets'. (In addition, the `ASSET_FIELD_NOT_LIST` code should be `ASSETS_FIELD_NOT_LIST` but I did not fix that.)
I also refactored all of the code to be more modern:
* Use `var` instead of types in declarations
* Short circuit error-and-return with `if (foo is! YamlMap)`. We didn't use to have promotion here, but this led to a wild amount of nesting (if, if, for, if, if, else, if!).
Change-Id: Ia489ea631f7d1027fdb84a9a682c831752c5835c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338593
Reviewed-by: Marya Belanger <mbelanger@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The AST-to-IR conversion stage now handles the AwaitExpression,
YieldStatement, and IsExpression AST nodes. This required adding the
`await_`, `yield_`, and `is_` instructions.
I believe this completes the proof-of-concept phase of AST-to-IR
conversion. I plan to move on now to implementing some lint rules
based on the IR representation.
Change-Id: I5f6e920dd04ca23d6b90d1522abf32955f757bc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337280
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The AST-to-IR conversion stage now handles the DoStatement and
WhileStatement AST nodes, as well as simple ForStatement nodes (those
whose `forLoopParts` is `ForPartsWithDeclarations`). This required
adding the `loop` instruction. Unlabeled `break` and `continue`
statements are also supported.
Change-Id: Iaa46245755087e9f905988d65c4c2e0c33d283ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337041
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The AST-to-IR conversion stage now handles the MethodInvocation AST
node (which is used for both method invocations and top level function
invocations). This required adding the instruction `identical`, to
support invocations of the `identical()` function.
Change-Id: I7a4204f50c770874ff913e2cbeabb997958025c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336829
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The AST-to-IR conversion stage now handles if statements, conditional
expressions, unary `!`, and binary `!=`. This required adding the
instruction `not`.
Change-Id: I2c87f95d8dfa1967ebe6c92c789c16254779c5bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336821
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The AST-to-IR conversion stage now handles null-shorting property
accesses (both for reads and writes). This required adding the
following instruction types: `eq`, `block`, and `brIf`.
In order to make `eq` easier to test, support was also added for
AST-to-IR conversion of testing binary expressions using `==`.
The way null shorting is encoded in the IR is by issuing a `block`
instruction when null shorting starts, and an `end` instruction when
it terminates. Anywhere a null check appears within the null shorting
expression, the null check uses a `brIf(0)` instruction to branch to
the `end` in the case a `null` is found. To make it easier to keep
track of when `block` and `end` instructions need to be generated,
`RawIRWriter` keeps track of a count of the current nesting of control
flow contsructs.
In order for the interpreter to find to the appropriate `end`
instruction when a branch is taken, a new scope analyzer is
added. Later CLs will expand on it and use it for static analysis as
well.
Change-Id: I09ca34eaa900d47f7a4014cbc8db2a48a1d69e1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336800
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The AST-to-IR conversion stage now handles reads and writes of
properties, whether through a `SimpleIdentifier` (via implicit
`this`), a `PrefixedIdentifier`, or a `PropertyAccess` AST node. In
order to make this easier to test, support was also added for
parenthesized expressions.
This required adding the following instruction types: `call` and
`shuffle`. To allow for thorough testing, support for these
instruction types was added to the interpreter and validator.
Change-Id: Ic60452422a877f358b0cad31b3c5664fd0585809
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335701
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This is a reland of commit b76d60340d
Original change's description:
> Add support for non-late local variables to the Wolf analysis prototype.
>
> The AST-to-IR conversion stage now handles function parameters, local
> variable declarations, `this`, and reads and writes of local
> variables. In order to make this easier to test, support was also
> added for block function bodies, expression statements, and return
> statements.
>
> This required adding the following instruction types: `alloc`, `br`,
> `drop`, `dup`, `readLocal`, `release`, and `writeLocal`. To allow for
> thorough testing, support for these instruction types was added to the
> interpreter and validator.
>
> Change-Id: Iedef6aa75297081d128e89a2ac24019a198cf948
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335505
> Commit-Queue: Paul Berry <paulberry@google.com>
> Reviewed-by: Phil Quitslund <pquitslund@google.com>
Change-Id: I660947ff7adc6173508dcd69f625ced7e1d35721
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336202
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This reverts commit b76d60340d.
Reason for revert: Cbuild failures (old version of package:checks used internally)
I'll fix the internal code to use the latest package:checks before re-landing.
Original change's description:
> Add support for non-late local variables to the Wolf analysis prototype.
>
> The AST-to-IR conversion stage now handles function parameters, local
> variable declarations, `this`, and reads and writes of local
> variables. In order to make this easier to test, support was also
> added for block function bodies, expression statements, and return
> statements.
>
> This required adding the following instruction types: `alloc`, `br`,
> `drop`, `dup`, `readLocal`, `release`, and `writeLocal`. To allow for
> thorough testing, support for these instruction types was added to the
> interpreter and validator.
>
> Change-Id: Iedef6aa75297081d128e89a2ac24019a198cf948
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335505
> Commit-Queue: Paul Berry <paulberry@google.com>
> Reviewed-by: Phil Quitslund <pquitslund@google.com>
Change-Id: I4ae22c6e0dfcd9ae7d60c994b5bde8dc24158105
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335950
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
The AST-to-IR conversion stage now handles function parameters, local
variable declarations, `this`, and reads and writes of local
variables. In order to make this easier to test, support was also
added for block function bodies, expression statements, and return
statements.
This required adding the following instruction types: `alloc`, `br`,
`drop`, `dup`, `readLocal`, `release`, and `writeLocal`. To allow for
thorough testing, support for these instruction types was added to the
interpreter and validator.
Change-Id: Iedef6aa75297081d128e89a2ac24019a198cf948
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335505
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Wolf analysis is an experimental part of the analyzer that I intend to
use as the basis for new, more advanced, lint rules and other
analyses. Its first phase will consist of lowering the abstract syntax
of each function or method to a stream of instructions for a minimal
stack machine.
This code implements the first few instructions for the minimal stack
machine (`function`, `end`, `literal`, and `drop`). These are
sufficient to express a simple function like:
int f() => 0;
Which maps to the following instruction stream:
function(int Function(), 0)
literal(0)
end
This code includes a validator that verifies that an instruction
stream is well-formed. In follow-up CLs I will add logic to convert an
analyzer AST to an instruction stream.
The internal representation of an instruction stream is code
genreated, because:
- I intend to add additional instructions in follow-up CLs, and I
don't want to have to remember all the boilerplate for adding an
instruction each time.
- Once the implementation is far enough along to start consuming large
amounts of real-world Dart code, I would like to be able to
investigate the performance effects of changing the internal
representation. Code generation will make this a lot easier.
Change-Id: I4bc299d31ed108f6eebf9cca913d1484dbc9a3cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334644
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
A [Uint8List] may be a view into a larger buffer. When we want to create
a corresponding [ByteData], we should ensure the byte data is based on
the same bytes (and not e.g. include additional heading/trailing bytes)
by using `bytes.buffer.asByteData(bytes.offsetInBytes, bytes.length)`
Change-Id: Ifd7b59a41b8ee0431319d5cf13a2e63da3dfb00e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330080
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Will warm up the memory cache and then measure how much live memory the analyzer consumes after visiting all elements with the warmed up cache.
All results
--------------------------------
flutter_elements
reachableObjects
count: 9071480
size: 799672175 = 780929 KB = 762 MB
_SimpleUri
count: 3112
size(shallow): 248960 = 243 KB
duplicateCount: 0
Change-Id: I75209f88f6f615172127cd439afe9d0cd83b1c4f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329682
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
We rely on the result of the `ConstantVisitor` to indicate whether we have an error or a valid constant value.
This CL changes `evaluationResult` to be a `Constant` and changes error reporting to occur at a POE for evaluating a constant.
Last few chunks of cleaning up the constant evaluator, woo!
Change-Id: Icd41a4fcbab0626df36c6a83cd60ecbb59c2dcf0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324573
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This passes the first token of these top level declaration directly
to the endX listener method.
In the CFE this is used to ensure that can handle the new modifiers in
the textual outline. Furthermore, support for extension types is added
and having an "unknown chunk" now results in an error. The latter should
help us keep the textual outline up-to-date wrt new features.
Change-Id: I813d6162b6cba0a2bf550ed33a6091abf9bf49f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324702
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This looks pretty beefy; it is more-or-less 3 parts:
* Removing the `implicit-casts: false`, `implicit-dynamic: false`
modes:
* Remove `AnalysisOptionsFileConfig.implicitCasts|implicitDynamic`
* Remove `AnalysisOptionsImpl.implicitCasts|implicitDynamic`
* Remove `TypeSystemImpl.implicitCasts`
* Remove all behavioral tests of the modes
* Remove Analysis Options-parsing code that handled `strong-mode`
* Remove ability to fix deprecated modes (introduced before Dart 3).
* Move some non-generated AnalysisOptionsHintCodes and
AnalysisOptionsWarningCodes to be generated. As
`AnalysisOptionsHintCode.STRONG_MODE_SETTING_DEPRECATED` was the
last `AnalysisOptionsHintCode` code, there were problems with the
code-generator, unless I moved these non-generated codes.
* `DEPRECATED_LINT_HINT`, `DEPRECATED_LINT_HINT_WITH_REPLACEMENT`,
`DUPLICATE_RULE_HINT`, `INCOMPATIBLE_LINT`, `UNDEFINED_LINT`.
* Those codes are then added to error_fix_status.yaml.
Change-Id: Ic165b60ca85f08f92886433eac5f5da5b7dd5021
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316483
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
And using Future from dart:core, which was not enabled until Dart
2.1.0.
Dart 3's minimum language version is 2.12. google3's is 2.9.
Change-Id: Id31d92007e685447ff217bdccf8161c8fd6ce6e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316863
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
**Context:**
The `platforms` field is used to indicate what platforms are supported
by a given package. It's only relevant when publishing to pub.dev, or
similar package repository. If no `platforms` fields is supplied the
platforms will be detected based on `import` statements, also accounting
for conditional imports. See [pubspec reference][1] for details.
These diagnostics aim to help developers discover a misconfigured
`platforms` fields, which they would otherwise only discover when
publishing to [pub.dev][2].
[1]: https://dart.dev/tools/pub/pubspec#platforms
[2]: https://pub.dev
Change-Id: I7b9ea5e371bb1cce6410d32fe6f38c49bc2ff69e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309661
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Marya Belanger <mbelanger@google.com>
Commit-Queue: Jonas Jensen <jonasfj@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Sam Rawlins