This CL primarily adds a lint for fields with `StackTrace.current`
which is often useful for debugging, but shouldn't be left in.
* Add an ast visitor after the "explicit creation test",
finding - for now - `StackTrace.current` calls in fields.
This should have caught the left-in debug such in
https://dart-review.googlesource.com/c/sdk/+/379281.
* Renamed explicit_creation to compile_and_lint
* Remove (for some time) unused "smoke_test_quick" files.
* Add kernel to the compile_and_lint suite, but ignore it for explicit
creation (i.e. kernel will also be checked for fields
with `StackTrace.current`).
Change-Id: Ib886d23a8945e7063dc673a7f99cbb3a6adc1139
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382361
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously, performSubtypeConstraintGenerationForFutureOrLeftSchema
and performSubtypeConstraintGenerationForFutureOrRightSchema had
almost identical implementations. The purpose of those methods was to
provide two differently typed entry points to the same algorithm. This
CL reduces the code duplication by introducing
performSubtypeConstraintGenerationForFutureOrInternal that the two
entry points simply redirect to.
Part of https://github.com/dart-lang/sdk/issues/54902
Change-Id: Idd545eed3cba67882f81b68e9b69ccf1aecb4257
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382164
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
The scanner, when creating StringTokens cuts out the substring lazily if
their length is above some threshold. The work is then only done when
and if we actually need the string.
This makes sense for the cases where we normally do not need the string.
In the CFE we scan all sources twice: Once for building the outline, and
once for building the bodies.
When building the bodies we in almost always actually need the string
anyway (something along the lines of we don't ask for <400 out of over
400,000 when compiling the CFE itself).
This CL opts the CFEs second scan (when building bodies) out of the lazy
strings, copying the substrings up front, avoiding the creation of
intermediary `_LazySubstring` (`_CompactLazySubstring` /
`_FullLazySubstring`).
With an AOT compile of the CFE, compiling itself, 50 runs gives these
statistics:
```
msec task-clock:u: -1.3619% +/- 0.3329% (-57.88 +/- 14.15)
page-faults:u: -1.1453% +/- 0.0162% (-1163.82 +/- 16.44)
cycles:u: -1.4138% +/- 0.3433% (-248274774.52 +/- 60279949.79)
instructions:u: -0.5573% +/- 0.0003% (-120171914.10 +/- 59862.46)
branch-misses:u: -3.2906% +/- 1.4496% (-2192237.90 +/- 965762.85)
seconds time elapsed: -1.3662% +/- 0.3338% (-0.06 +/- 0.01)
seconds user: -1.3354% +/- 0.3715% (-0.05 +/- 0.01)
Scavenge( new space) goes from 63 to 62
```
25 other runs gave these:
```
msec task-clock:u: -0.7929% +/- 0.4759% (-33.69 +/- 20.22)
page-faults:u: -1.1654% +/- 0.0176% (-1184.36 +/- 17.88)
cycles:u: -0.7756% +/- 0.5043% (-136122352.96 +/- 88506748.30)
instructions:u: -0.5578% +/- 0.0005% (-120265633.72 +/- 115062.27)
seconds time elapsed: -0.7852% +/- 0.4726% (-0.03 +/- 0.02)
Scavenge( new space) goes from 63 to 62
```
So it seems likely that new space GCs go from 63 to 62, theat the
instruction count goes down by 0.55% and that it's actually around 1% faster.
Change-Id: Ic462a67db7274cc8ed38df7f3ed9f41f7497fc82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382162
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL removes Type and TypeSchema type variables from the abstract
classes with shared code between the CFE and the analyzer. Extension
types SharedTypeView and SharedTypeSchemaView are declared to replace
the type variables.
The update propagates the discipline of distinguishing between types
and type schemas into the clients of the shared code. Now the code in
the CFE and the Analyzer that uses the shared code needs to statically
specify the interpretation of their type objects as either types or
type schemas.
Another benefit of the update is SharedTypeView and
SharedTypeSchemaView being less opaque than the Type and TypeSchema
type variables, which removes the necessity for some code duplication
in abstract methods for types and type schemas.
Finally, the update enables some further changes in the shared code
between the Analyzer and the CFE.
Change-Id: I88e8cfcd47d4f721974b4f2612521e85bb54c30f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379302
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This adds an explicit computation for the nullability of type variables
while taking cyclic dependencies into account. This removes the need
for post-processing of pending nullabilities.
Change-Id: Ic7c42eef8270610d3b4f1d27ea0067c80df88daa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381242
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This changes the BodyBuilder to create FunctionTypeParameter instead
of FormalParameterBuilder for "parameters" in function types. This
avoids the creation of unnecessary VariableDeclaration nodes
function types.
The types of these VariableDeclarations where created before the type
variable scope was completed, introducing an artificial dependency on
the pending nullability computation.
Change-Id: Ie1203fa4c78a27f3e7a0dfad16725cbbde24a6a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381143
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
SharedType and its subtypes now all declare one recursive type
variable Type with the bound SharedType<Type>. It allows to treate
SharedType and its subtypes as an abstract familty of types that has a
specific structure.
More specifically, the type variables Type and TypeSchema in the
abstract classes for shared algorithms between the Analyzer and the
CFE can now be defined recursively as extending SharedType<Type> and
SharedType<TypeSchema>, giving both types and type schemas the
structure of the family of types with the root at SharedType.
One of the benefits for that is that some abstract members become
unnecessary. For example, a type or type schema can now be tested for
having the shape of the type 'dynamic' with a direct is-check,
comparing them, correspondingly, with SharedType<Type> and
SharedType<TypeSchema>.
More importantly, having the family of recursive types lays the
foundation for further work on sharing the type structure between the
Analyzer and the CFE.
Change-Id: I67904f878668c035702092e8c21d3ce66f5ca469
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378700
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Adds a new `@Array.variable()` to specify that the last element of
structs is a variable length inline array.
This CL does not add any checks for passing structs with variable
length inline arrays by value or directly calling them with
`AllocatorAlloc.call`. Instead, the implementation defaults to what
C does, allocate as if there are 0 elements in the variable length
inline array.
TEST=tests/ffi/*
CoreLibraryReviewExempt: VM only
Closes: https://github.com/dart-lang/sdk/issues/55964
Change-Id: I524d8a1d710b1a744b392e05fa884908c3ff1f12
Cq-Include-Trybots: dart/try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-asan-linux-release-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-msan-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-tsan-linux-release-x64-try,vm-aot-ubsan-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,vm-aot-win-debug-x64c-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-arm64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-arm64-try,vm-fuchsia-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-arm64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-tsan-linux-release-arm64-try,vm-tsan-linux-release-x64-try,vm-ubsan-linux-release-arm64-try,vm-ubsan-linux-release-x64-try,vm-win-debug-arm64-try,vm-win-debug-x64-try,vm-win-debug-x64c-try,vm-win-release-ia32-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371960
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This should help keep documentation comments up to date and
meaningful, and it will ensure that when parts of _fe_analyzer_shared
are re-exported as part of the analyzer API, the generated
documentation will have working links.
Change-Id: I9296db3a142a690e4191eb9443d1818d05279fa0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/376463
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The shared abstract class TypeConstraintGenerator is introduced and is
set as the parent for both the Analyzer's TypeConstraintGatherer and
the CFE's TypeConstraintGenerator. The interface of the shared
abstract class is minimal, to support the treatment of the discrepancy
between the Analyzer and the CFE around FutureOr types.
The discrepancy between the Analyzer and the CFE is seaprated out into
a smaller method and can be controlled via a boolean flag that
switches between the behaviors of the two frontends. The flag is
called requiredEmptyNullabilitySuffix and is passed as a named
parameter to
TypeConstraintGenerator.performSubtypeConstraintGenerationForFutureOr.
In response to https://github.com/dart-lang/sdk/issues/55344
Part of https://github.com/dart-lang/sdk/issues/54902
Change-Id: I272b57b573377a54977a516ce6e378953bd1c0e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373480
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Fix bracketed references in doc comments that previously pointed to
nowhere, in the shared parser
(pkg/_fe_analyzer_shared/lib/src/parser/...) and scanner
(pkg/_fe_analyzer_shared/lib/src/scanner/...).
This is part of a larger effort to clean up _fe_analyzer_shared to the
point where the `comment_references` lint can be enabled.
Change-Id: I60c402d9b4df50208ed51587e71a0663e369d622
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375221
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fix bracketed references in doc comments that previously pointed to
nowhere, in the shared exhaustiveness logic
(pkg/_fe_analyzer_shared/lib/src/exhaustiveness/...).
This is part of a larger effort to clean up _fe_analyzer_shared to the
point where the `comment_references` lint can be enabled.
Change-Id: I743cf6537316ba14ffbb90e9d93fb67c451bb308
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375220
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fix bracketed references in doc comments that previously pointed to
nowhere, in the following source files:
- pkg/_fe_analyzer_shared/lib/src/testing/id_testing.dart
- pkg/_fe_analyzer_shared/lib/src/util/colors.dart
- pkg/_fe_analyzer_shared/lib/src/util/options.dart
- pkg/_fe_analyzer_shared/lib/src/util/value_kind.dart
This is part of a larger effort to clean up _fe_analyzer_shared to the
point where the `comment_references` lint can be enabled.
Change-Id: I3008246560e551819f836a02d8881eb1389077f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375202
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Fix bracketed references in doc comments that previously pointed to
nowhere, in the following source code:
- Shared type inference logic
(pkg/_fe_analyzer_shared/lib/src/type_inference/...).
- Testing infrastructure that exercises shared type inference logic
and flow analysis (pkg/_fe_analyzer_shared/test/mini_*.dart).
This is part of a larger effort to clean up _fe_analyzer_shared to the
point where the `comment_references` lint can be enabled.
Change-Id: I15e6133dc7631c9a634131f0df3a3ff14f568e3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375201
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fix bracketed references in flow analysis doc comments that previously
pointed to nowhere.
This is part of a larger effort to clean up _fe_analyzer_shared to the
point where the `comment_references` lint can be enabled.
Change-Id: I36a6968a7c25715d1420ae327ee0e14617d29b02
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375181
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Work towards https://github.com/dart-lang/language/issues/2
The feature is well-specified at the issue, but I will also follow
up with a specification to check into the language repo.
This change implements the feature more-or-less from front to back
(because the back is very close to the front in this case :P; no
"backend" work in the VM, etc). Digit separators are made available
via a new experiment, `digit-separators`.
Care is taken to report a single error when an underscore appears in
an unexpected position (see new `separators_error_test.dart`).
Three test files are added:
* `separators_test.dart` is run with the experiment enabled, and has
no compile-time errors.
* `separators_error_test.dart` is run with the experiment enabled, and
has many compile-time errors.
* `separators_error_no_experiment_test.dart` is run with the
experiment _disabled_.
Change-Id: I7f1b1305d28b708b5ddf83f26188cd6e9ce3dd58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365181
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The type inference logging infrastructure in the analyzer is built out
to include the following functionality:
- Tracking of type inference of annotations, collection elements,
patterns, and statements.
- Tracking of method lookups.
- Tracking of the generic type inference process, including type
formals, constraints that were generated (and their sources),
partial solutions, and the final types chosen.
It is not yet possible to invoke this functionality on the command
line; I plan to introduce a mechanism for doing so in a follow-up
commit.
Change-Id: I3f592a483b272fcea74c1e31bc51f2c5c3623bc6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363240
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The [StackListener.importUri] property is problematic because it assumes
or implies that when a compilation unit is being parsed, the import URI
for the containing library is known. This might not be the case if a part file is read before the main library file.
Currently the [StackListener.importUri] is only used to detect whether
the current file is part of a `dart:` library, so the property is replace with [isDartLibrary] which does just that.
Change-Id: I2d2baf2fe20bb62fd1922864c0e5af95e8fd1ca7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/372084
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Like type parameters, these parameters can't be passed from JS and
such functions already do not work as intended as there is no way
to pass named args to a JS function. These named parameters were
being silently ignored in dart2wasm when creating the function
trampoline.
Change-Id: Iebb890de05f8b242e0542c1ec8f2c0582c5232df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368062
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This commit updates the type inference logging logic introduced in
https://dart-review.googlesource.com/c/sdk/+/369788 so that it
additionally tracks the context and static type for each inferred
expression.
Tracking the context for each expression is easy, since it is an input
to the type inference algorithm, passed in to each `visit` method of
`ResolverVisitor` through the named parameter `contextType`. However,
there were a few expression types for which the context type *wasn't*
passed in, because it wasn't used (for example
`ResolverVisitor.visitBooleanLiteral`, since boolean literals always
have the same meaning regardless of their context). `contextType`
parameters have been added to these `visit` methods for consistency
with the other expression visit methods, so that the type inference
log shows the context for all expressions, whether it makes a
difference to inference or not.
Tracking the static type for each expression is a little trickier,
since it's not an explicit output of the type inference algorithm, but
rather the static type of each expression is set as a side effect of
the type inference mechanism. To make things more tractable, the
`ExpressionImpl.staticType` field is made private, and instead of
setting it directly, the resolver must set it by either calling
`recordStaticType` or `setPseudoExpressionStaticType`. The former is
used when resolving a real expression; the latter is used for
situations where the analyzer assigns a static type to an AST node
even though that AST node isn't really serving as an expression
according to the official language specification. (For example, when
analyzing the method invocation `x.foo()`, the analyzer stores a
static type on the SimpleIdentifier `foo`, even though according to
the language spec, `foo` in this context actually isn't an expression
in its own right).
Splitting the code paths that set static types into `recordStaticType`
and `setPseudoExpressionStaticType` allows for the type inference
logging mechanism to check some useful invariants: it verifies that
every expression that the resolver visits is either assigned a static
type exactly once through a call to `recordStaticType`, or it's
determined to not be a true expression (and hence not assigned a
static type at all); I believe the latter happens mostly when
analyzing erroneous code, or when the resolver visitor is called upon
to assign a type to an identifier that's in a declaration context.
Change-Id: Icdf023d03fba3c87dbec3a72d00d0e9c7d1da5fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370322
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is the first in a planned series of commits that will give the
analyzer and the CFE the ability to instrument their type inference
functionality. The eventual goal is to have an easy way for developers
of the Dart SDK (and perhaps even curious customers) to supply some
code to the analyzer and/or CFE, and see a trace of the relevant type
inference events (e.g. when each statement, expression, pattern, or
collection element was type inferred, the context supplied to type
inference of each expression, the static type of each expression, the
steps involved in inferring generic type parameters, significant flow
analysis events, etc.).
For now, the only functionality that is implemented is to track when
the `ResolverVisitor` enters and exits each expression. This is done
by adding the null-aware calls
`inferenceLogWriter?.enterExpression(...)` and
`inferenceLogWriter?.exitExpression(...)` to each expression `visit`
method in the `ResolverVisitor`.
In normal operation, `inferenceLogWriter` returns `null`, so there is
no effect. But when type inference logging is active, this call
triggers information to be recorded in memory. This information can be
printed to standard output in two scenarios: (1) if the user requests
type inference logging (not yet implemented), or (2) if the type
inference logging mechanism detects that an important invariant has
not been satisfied (e.g. improper nesting of `enterExpression` and
`exitExpression` calls).
This mechanism of using null-aware calls for instrumentation is very
low overhead when inference logging is inactive; I've verified using
Golem that the overhead is well below the noise level of all our
benchmarks (this Golem run was done using a private branch in which
inference logging is more completely fleshed out, to try to provoke
the most overhead possible). Details can be found here:
https://golem.corp.goog/Comparison?repository=dart#targetA%3Ddart-analysis-server%3BmachineTypeA%3Dlinux-x64%3BrevisionA%3D110445%3BpatchA%3Dpaulberry-inference_log%3BtargetB%3Ddart-analysis-server%3BmachineTypeB%3Dlinux-x64%3BrevisionB%3D110443%3BpatchB%3DNone
Note that the expression visit methods in `ResolverVisitor` are
invoked in two ways depending on the surrounding code: via the
abstract function `ExpressionImpl.resolveExpression` (when supplying a
context) and via the standard visitor mechanism (typically using
`AstNode.visitChildren`). So there is no single unique function
involved in all expression type inference. This means that in order to
fully instrument expression inference, every single expression visit
method in `ResolverVisitor` must call `enterExpression` and
`exitExpression`. It would be very easy to get this wrong, and forget
to instrument an important expression type.
Two mitigation strategies were used to reduce the risk of an
expression type getting forgotten. Firstly, the
`ResolverVisitor.dispatchExpression` method (which is a
frequently-used entry point for type inferring an expression) calls
`inferenceLogWriter?.assertExpressionWasRecorded` after visiting the
expression; this checks that `enterExpression` was properly
called. Secondly, each time `enterExpression` is called, the inference
logging mechanism looks through the ancestors in the AST, and checks
that `enterExpression` was also appropriately called for the innermost
enclosing expression.
To make sure that the analyzer really satisfies the invariants that
these checks are checking, the type inference logging mechanism is
turned on when assertions are enabled (but it is turned on in a way
where it only dumps to standard out if something goes wrong). This
ensures that the checks will be verified when running analyzer unit
tests on the trybots, but doesn't introduce any extra overhead the
production analyzer (beyond the null-aware calls mentioned earlier).
In follow-up commits I intend to add logic to do the following:
- Track the context and static type of each expression.
- Track type inference of statements, patterns, and collection
elements.
- Track the computations involved in solving for generic type
parameters.
- Add a command-line mechanism that developers of the Dart SDK can use
to analyze some code with type inference logging enabled.
Change-Id: I9757bdd2b3cb996fc98b615d87991de16674e53b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369788
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The agnostic mode was added to allow the platform dill embedded in
the VM to support both weak and strong mode. Since weak mode is no
longer supported in the VM, the agnostic mode can new be deleted.
All uses of the agnostic in Dart and Flutter have been removed prior
to this change.
Change-Id: Iff0f69d9cd64e887e01cd7e7d336a97761bd6d4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366801
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Jens Johansen