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>
Followup to fb057ea4e0
Now that the web implementation of DateTime supports microseconds, the test special cases for not supporting microseconds can be removed.
Change-Id: I10991b25e42d643ae58850d7190621c9d11877b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367680
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This fixes a bug where a semantic tokens request could use an incorrect LineInfo for mappings if sent immediately after an overlay update because:
a) we computed a LineInfo from the source instead of using one consistent with the resolved unit
b) we read the file state in a way that did not take into account the latest overlay updates if the analysis driver hadn't handled the changed file
The second issue could affect other requests too because server.getLineInfo() is used in a number of places (to support plugins). This change reverts reading the file state directly, but also updates semantic tokens to prefer using the LineInfo from the resolved unit when we have one (only falling back to computing one from current sources for non-Dart files, which can be handled by plugins).
Fixes https://github.com/dart-lang/sdk/issues/55084
Change-Id: I77ab6ad63a78ebd062b264d901a9ae8568b9096e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370021
Reviewed-by: Sam Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Spelled out at https://github.com/dart-lang/linter/issues/1020
Fixes https://github.com/dart-lang/linter/issues/1020
This CL does not change the categories/groups that any rule has. We
can add/change categories in later CLs.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: Ief2856a6c472492bbad19fc95df172ef8d19fe7b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369861
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Sam Rawlins <srawlins@google.com>
Local variables named `_` are no longer in scope and can't be used when the wildcard variables experiment is enabled.
Bug: https://github.com/dart-lang/sdk/issues/55655
Change-Id: I13a7a9fcfb92e4b64bd51b5ccfe657f5a0633233
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369507
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
* Generalizes `RemoveExtraModifier` to a new `RemoveLexeme` producer that works for keywords and modifiers.
* Adds a new (keyword) quick-fix for the `GETTER_CONSTRUCTOR`
See: https://github.com/dart-lang/sdk/issues/55917
Change-Id: I0e7fbc33aa970f0754c9533b3ecbd4e9dd9ddb30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370100
Auto-Submit: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Revisions updated by `dart tools/rev_sdk_deps.dart`.
crypto (0a10171..7a9428a):
7a9428a 2024-06-04 Kevin Moore Bump lints dep (dart-lang/crypto#172)
dartdoc (45627f9..ddb8fb4):
ddb8fb44 2024-06-03 Konstantin Scheglov Use package:analyzer/source/source.dart (dart-lang/dartdoc#3780)
http (7bfbeea..a3567f8):
a3567f8 2024-06-05 Brian Quinlan Prepare to release cronet_http 1.3.1 (dart-lang/http#1228)
7addc61 2024-06-05 Hossein Yousefi [cronet_http] Upgrade jnigen to 0.9.2 to close `#1213` (dart-lang/http#1225)
eb87a60 2024-06-04 Anikate De pkgs/ok_http: Close the client (override `close()` from `BaseClient`) (dart-lang/http#1224)
9f022d2 2024-06-04 Anikate De pkgs/http_client_conformance_tests: add boolean flag `supportsFoldedHeaders` (dart-lang/http#1222)
90837df 2024-06-03 Anikate De pkgs/ok_http: Condense JNI Bindings to `single_file` structure, and add missing server errors test (dart-lang/http#1221)
logging (73f043a..dbd6829):
dbd6829 2024-06-04 Sarah Zakarias Update `topics` in `pubspec.yaml` (dart-lang/logging#165)
test (2464ad5..83c597e):
83c597e5 2024-06-05 Jacob MacDonald enable asserts in dart2wasm tests (dart-lang/test#2241)
60353804 2024-06-04 Nate Bosch Remove an unnecessary `dynamic` (dart-lang/test#2239)
43ad4cd8 2024-06-03 Kevin Moore random cleanup (dart-lang/test#2232)
18db77c3 2024-06-02 Kevin Moore prepare to publish test_api (dart-lang/test#2238)
cd72e8d8 2024-06-02 Kevin Moore Prepare to publish (dart-lang/test#2237)
9c6adaa7 2024-06-01 Kevin Moore fixes (dart-lang/test#2235)
0110a80b 2024-06-01 dependabot[bot] Bump the github-actions group with 2 updates (dart-lang/test#2236)
b1b2c029 2024-06-01 Martin Kustermann Fix `dart run test -p chrome -c dart2wasm` (dart-lang/test#2233)
tools (86b3661..4321aec):
4321aec 2024-06-05 Andrew Kolos [unified_analytics] Suppress any `FileSystemException` thrown during `Analytics.send` (dart-lang/tools#274)
e5d4c8b 2024-06-03 dependabot[bot] Bump actions/checkout from 4.1.5 to 4.1.6 in the github-actions group (dart-lang/tools#271)
web_socket_channel (45b8ce9..bf69990):
bf69990 2024-06-03 Thibault Chatillon bump web_socket dependency 0.1.3 -> 0.1.5 (dart-lang/web_socket_channel#370)
5b428dd 2024-06-02 dependabot[bot] Bump actions/checkout from 4.1.5 to 4.1.6 in the github-actions group (dart-lang/web_socket_channel#371)
afd1e3c 2024-05-23 Brian Quinlan Remove `--fatal-infos` from `dart pub downgrade` analysis (dart-lang/web_socket_channel#367)
cb20b71 2024-05-23 Sarah Zakarias Add `topics` to `pubspec.yaml` (dart-lang/web_socket_channel#362)
8514229 2024-05-22 Kevin Moore Bump and fix lints (dart-lang/web_socket_channel#366)
webdev (a97c2a1..9ada46f):
9ada46fc 2024-06-05 Nicholas Shahan Hide more temporary variables when debugging (dart-lang/webdev#2445)
yaml_edit (963e7a3..08a146e):
08a146e 2024-06-06 Kavisi Fix splice list insertion (dart-lang/yaml_edit#84)
561309e 2024-06-01 dependabot[bot] Bump actions/checkout from 4.1.5 to 4.1.6 in the github-actions group (dart-lang/yaml_edit#85)
b582fd5 2024-05-31 Kavisi Fix error thrown when inserting keys (dart-lang/yaml_edit#80)
Change-Id: I36acbc26fe97d8a1e3fdfa5f4855cc4be7d84dd7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370080
Commit-Queue: Devon Carew <devoncarew@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, if a record literal had named fields, type inference of
the literal fields would happen as part of the process of
hoisting. This was a problem because the hoisting process requires
visiting the fields in reverse order, so as a result, the order in
which subexpressions were type inferred was the reverse of the order
in which they would be executed, leading to unsound type promotion
behavior.
Fixes#55914.
Bug: https://github.com/dart-lang/sdk/issues/55914
Change-Id: I2d8930e0e1d7579d065bfb850aa7472d28a8012c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369761
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
google3 makes heavy use of symlinks, with no guarantee that the relative
location of files with respect to each other will be maintained after
the symlinks are resolved. This causes issues when trying to locate the
DartDev snapshot using the VM executables resolved path as a base.
This change updates the DartDev snapshot detection logic to first try to
find the snapshot using the resolved executable path before falling back
to using the unresolved path used to launch the VM (e.g., the path
specified by argv[0]).
TEST=pkg/dartdev/test/
Change-Id: I19a41c440ac82cbc671dafb3bda23a31fb4cdc0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370000
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>