This will simplify logic in clients parsing this information by
providing a clear signal that all connection data has been sent over the
stream and is ready to be decoded.
Change-Id: Iae3779fe13662bf15187e9fa41febba94af4f2c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370940
Commit-Queue: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Auto-Submit: Ben Konyi <bkonyi@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
When a class contains both a field and getter with the same name, we'd include both in the `variables` response. In most cases these are the same value (although it's not guaranteed).
I've chosen to just hide the field in this case and always show the result from evaluating the getter (since I think that's what the user would expect, even in the case where they happen to have different values). Another option could be to show both (but change the name so that fields/getters are shown differently), however in that would change the display (for example adding `get ` in front of all getters) we should probably only do that if it's clear there is demand for it.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5128
Change-Id: I9e23d22a844ee22c38988456b1f275422c5c9e04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370640
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This prints the commands needed to reproduce or generate expectations
for the macro application test.
Change-Id: Idf62ec8d8bdc846d2b043328b447f51839984c48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370883
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This is a reland of commit 35bc17a0fa
Changes from the original CL is that we now allow packages in
`allowedInteropLibrariesInDart2WasmPackages`.
Original change's description:
> [dart2wasm] Check import/export pragmas in user code
>
> Change-Id: I926d108a4571d685c67d3a174a8e506910cce8f7
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369020
> Commit-Queue: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: I69f61ecf246dfdbfcab372c6c2adb2a64f2d0b36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370900
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
So running `pkg/front_end/test/coverage_suite.dart --updateExpectations`
will update `pkg/front_end/test/coverage_suite_expected.dart` and a `git
diff` will give an overview of what changed.
Also save both number of hits and number of misses in the
"expect-file". If nothing else it will give some context
about what has changed.
Also cleanup json coverage output to be sorted and not
include "misses" that are also "hits" (the VM can give
this information).
Change-Id: I426681dde3d4d2ad0a9a7dfa474292c699223d68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370520
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This is a follow-up to [0]. That CL changed dart2wasm's modular
transformer to issue an error if `dart:ffi` is imported.
Users of packages that have specialized code for the VM (which supports
FFI) use conditional imports based on `dart.library.ffi`. We don't want
the VM-specific code to be used for web in dart2wasm (as dart2wasm
doesn't support the entirety of `dart:ffi`).
As a result we're going to make `dart.library.ffi` be false in
coditional imports (as well as in
`const bool.fromEnvironment('dart.library.ffi')`).
[0] https://dart-review.googlesource.com/c/sdk/+/368568
Issue https://github.com/dart-lang/sdk/issues/55948
Issue https://github.com/flutter/flutter/issues/149984
Change-Id: I70a775278ab701d1fd2596521e378cb6364edac2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370580
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Add an additional base argument to Assembler::AddScaled so it now
computes:
dest <- base + (index << scale) + offset
If base is kNoRegister (or ZR when available), then it emits
instructions optimized for computing:
dest <- (index << scale) + offset
(i.e., its previous implementation)
Add AddScaled to AssemblerBase to ensure the same interface across all
architectures.
Rework the backend of CalculateElementAddress to use AddScaled
appropriately, which unifies it across architectures.
TEST=ci (refactoring)
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-simarm_x64-try,vm-aot-linux-debug-simriscv64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-linux-debug-simriscv64-try,vm-mac-debug-arm64-try,vm-aot-mac-release-arm64-try
Change-Id: I33c8f99604b68360f10b79050bd66ceb9d65ac9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370504
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Adds the `isWildcard` flag to variables. Will be using this for producing better errors.
TEST= Existing expectations tests for wildcards pass with new flag.
Bug: https://github.com/dart-lang/sdk/issues/55655
Change-Id: If2f7a5555e7cc26e84d1b1e63e4261c81a157d78
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370062
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Kallen Tu <kallentu@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>
Test to ensure that `avoid_unused_constructor_parameters` doesn't overreport in the presence of an unused wildcard param.
(Note that underscores are ignored pre-wildcards too and this ensures that that behavior is preserved too.)
Fixes: https://github.com/dart-lang/linter/issues/4995
Change-Id: I13ef73eb28cf2501ed292dd3c56c9933a8feefa9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370540
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Our tests (including code in core libraries) are never run with
assertions enabled.
=> Add the necessary configuration support in test_matrix.json
=> We'll then add a new builder running one configuration with asserts.
Change-Id: Id1bc27ddf7d683846510af4711679ad14f0e4168
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370620
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This adds CompilationUnit as a supertype of LibraryBuilder as a
first step towards splitting libraries from compilation units.
The SourceLoader._builders are now compilation units and lookups
in to the SourceLoader are split into compilation units, loaded
library builders and source library builders.
Change-Id: If9958a5a67443170cc1a538106d9efd424e36889
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369643
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Dead Code Elimination can remove `RecordCoverageInstr`, but shouldn't.
This CL makes it stay by returning true in `HasUnknownSideEffects`
making `MayHaveVisibleEffect` return true, making Dead Code Elimination
keep it.
Note that `RecordCoverageInstr::Canonicalize` will still let it go away
if the position is already covered which is what we want.
Bug: https://github.com/dart-lang/sdk/issues/42061
TEST=pkg/vm_service/test/coverage_closure_call_after_optimization_test.dart,vm/cc/IL_RecordCoverageSurvivesOptimizations
Change-Id: Ifd72f9071a51924fd71f3dae91687acb1467047d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370220
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Currently if we have a `<obj> is/as Iterable<T>` check we will
* allocate a `WasmArray<_Type>` array and put value for `T` in it
* allocate a `_InterfaceType` object with the array as type arguments
* call to RTT which is looping over the type arguments array
With this CL we recognize in the compiler if we generate tests against
interface types and specialize the most common cases (0, 1 or 2 type
arguments). This in return will make us
* call to 0/1/2 specialized RTT isInterfaceSubtype implementation
which will use unrolled loops to do the checking.
=> We avoid allocation of `_InterfaceType` always
=> We avoid allocation of `WasmArray<_Type>` for length=0/1/2
=> We have faster checking due to unrolled loops.
(It is very unlikely binaryen can achieve the same, as it would
need to do very aggressive inlining & loop unrolling to get to the
same result. If we'd force it to inline then every is/as check
would be very large).
Issue https://github.com/dart-lang/sdk/issues/55516
Change-Id: Ia99548d514683f678178ea30d07aeb742ae914ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370260
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
We make the compiler emit a special index (namely 0) into the
canonical type argument substitution table iff no substitution has to be
performed.
This is very common:
```
class List<T> implements Iterable<T> {}
```
=> The translation of the type arguments from `List` to those of
`Iterable` is a NOP and can therefore be skipped.
Issue https://github.com/dart-lang/sdk/issues/55516
Change-Id: I16ad8d7196656dddeba15801e80c2e23ae0af51b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370242
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
When an implicit or explicit `as` check fails we throw a [TypeError]
exception with a stack trace. Though that stack trace doesn't really
have to have the top-frame being where the check failed, it's fine if
there's an additional frame from the runtime code that actually throws
the exception.
Doing so removes `StackTrace.current` from every `as` check and
therefore reduces size.
Change-Id: Ia34b59ebaa54b8cdcd2dc7b153a1e4e2fe1dd0e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370340
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL optimizes the RTT data structures by
* Having a canonical table for substitution arrays
* Stores the (canonical) substitution index to use right next
to the super class id, thereby
* Removing an indirection when looking up substitutions
See more information in `sdk/lib/_internal/wasm/lib/type.dart`
This reduces
* `Hello.Compile.Size.wasm.opt` by ~ 4%
* `FluteComplex.Compile.Size.wasm.opt` by ~0.5%
Issue https://github.com/dart-lang/sdk/issues/55516
Change-Id: If0a50780a9a604886bd67a08a2f345103f0bcb32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369641
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The implicit covariance type checks are currently performed by always
calling out to RTT. Those can use our existing optimized implementation
for is/as checks.
This reduces code size of -O2 mode as well as makes certain
benchmarks significantly faster (e.g. UIMatrix* 2x faster)
Change-Id: Ib5224a310b2188b9edb2de1e800d2e60010d11f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370280
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
