This uses the previously added `%ignore=` syntax to enable validation of
the diagnostic documentation for several diagnostics that were
previously not being validated.
In the process I also cleaned up a few of the code snippets used in
those docs in order to minimize the number of ignored diagnostics.
I removed the newly validated diagnostics from the list in the validator,
and improved the comments for the ones that are still being ignored to
show why they're ignored and point to some possible future remediations
that would allow them to also be validated.
Change-Id: I46b0eeaab86740ba82784987e84f3e93046d39f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494941
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds validation that plugin diagnostics are configured with one
of the valid values (taken from one of the test cases):
```
plugins:
one:
diagnostics:
code1: ignore
code2: warning
code3: error
code4: info
```
Change-Id: I2a77988c2efe1d9e0fdcd33558ed970fbe4c47c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494781
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In `_SyncContext._checkValidReturn`, the call to `ensureAssignable` is
guarded by a check that `expressionType is! VoidType`. Therefore it's
not necessary to pass `isVoidAllowed: true` to
`ensureAssignable`. Removing this argument reduces the number of uses
of `isVoidAllowed` in the front end, which makes it easier to reason
about front end void checks.
Change-Id: I8bb30ca02941843dfb489045fcac536e6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/493484
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Presence of a control socket might indicate that another isolate has
started the perf witness server, but it can also be a stale file
from a dead process with the same pid. In the later case we need to
handle a SocketException, which will happen when we try to
connect to this socket and purge stale control socket.
Fixes https://github.com/dart-lang/sdk/issues/62966
TEST=test added
Change-Id: Id4310bea3d469418dc7324de64f084af6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495320
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Dynamic modules may make dynamic calls to compiled methods that had no
dynamic calls in the original whole world compilation. If this happens,
then dynamically create an interpreted dynamic invocation forwarder that
then appropiately checks and delegates to the compiled function.
TEST=co19/LibTest
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try
Change-Id: I283ca501f50118606650cf434b8debe30a43f676
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494520
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
In the new variable model `this` is treate as a variable. Similarly to
other variables, it is placed into a variable context, which is
treated as the point of declaration of `this` variable. Since
parameter lists of a `FunctionNode`, such as
`FunctionNode.positionalParameters` and
`FunctionNode.namedParameters`, aren't treated as declarations either,
but rather as a convenient way to access the parameters, a similar
treatment of `this` variable is introduced in this CL, where it
becomes accessible via `FunctionNode.thisVariable`, in addition to
being declared in an appropriate variable context.
Part of https://github.com/dart-lang/sdk/issues/61572
Change-Id: Ia608fd01661353eb704de225f6b123900b1671b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494840
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
_resolveNearestExistingPath safely resolves symbolic links by traversing up the tree until an ancestor exists, but it previously dropped the components of the path that were skipped. This causes non-existent dummy paths used in tests to incorrectly resolve to filesystem roots (like C:\ on Windows or / on POSIX), causing permission check failures.
This fix computes the relative path suffix between the original path and the closest existing ancestor using path.relative, and appends it back to the resolved path with path.join. POSIX dummy path coverage has also been added to verify identical behavior across platforms.
Fixes: https://github.com/dart-lang/sdk/issues/63147
Change-Id: Iac908998f052ad9054e8213ba059156a5982a301
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495000
Reviewed-by: Jessy Yameogo <yjessy@google.com>
Auto-Submit: Ben Konyi <bkonyi@google.com>
Commit-Queue: Jessy Yameogo <yjessy@google.com>
Replace the generic executable substitution helper with
`forSubstitution()` methods on internal executable and member elements.
This moves the logic for creating substituted constructors, methods,
getters, and setters onto the corresponding element implementations.
Each element kind can now decide whether a substituted wrapper is
needed, reject invalid cases such as non-member accessors, and combine
nested substitutions in a single place.
Also add `MapSubstitution.andThen()` so substituted elements can compose
an existing substitution with a new one directly, instead of rebuilding
maps ad hoc. This makes repeated substitution clearer and preserves the
intended order of application.
Overall, the change makes member substitution more explicit, removes
type casts and kind switches from the shared helper path, and keeps
substitution-specific behavior closer to the element types that own it.
Change-Id: I54a3bfea48ddf87b4db5c53094090f24d66a9a23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494780
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Use merged type parameters in BundleWriter
Use `withTypeParameters()` when writing type-parameterized fragments
instead of rebuilding a local scope from `fragment.typeParameters`.
The serialized data still comes from the fragment list, but the
resolution context now uses `fragment.element.typeParameters`. This
makes BundleWriter use the canonical merged type parameter elements when
writing bounds, default types, and other references that can point back
to those parameters.
Using the merged elements keeps the writer aligned with how later
resolution data refers to type parameters, especially when multiple
fragments are linked into a single element.
Also rename `_writeTypeParameterElement` to
`_writeTypeParameterFragment` to match what the method actually writes:
fragment declaration data, with element-backed resolution properties.
Change-Id: Iddcd7a4b15ad0717bd137da97813f761e0fba5eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494569
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Refactor `applicable_extensions.dart` so its public entry points accept
`DartType` and `ExtensionElement`, and perform implementation casts
internally at the analyzer boundary.
Remove the `strictCasts` parameter as well. Extension applicability
always ignores casts, so the parameter only added noise to the API and
to every call site.
Update completion and fix code in analysis_server to pass public types
directly and drop imports of internal analyzer type classes. Also
centralize the cast from `ExtensionElement` to `ExtensionElementImpl`
inside the helper instead of repeating it in multiple loops.
This makes the API cleaner, keeps the public/internal split in one
place, and reduces accidental coupling to analyzer implementation types.
Change-Id: I770ee5d8788f4c4a7004a0ad18a00cc52552e3b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494802
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This reverts commit 152cc247e0.
Reason for revert: Broken web_ui analysis (see flutter-analyze)
Original change's description:
> [dart2wasm] Split patch files by whether they use JS interop
>
> The eventual goal of the `dart2wasm_standalone` platform is to not rely
> on a JavaScript environment, which requires rewriting everything that
> currently relies on `js_interop` or `JS()` helpers.
>
> Since most of the patches are still written in Dart and we don't want
> to duplicate that code for the standalone target, this splits patch
> files by whether they rely on JS-interop or not. The main entrypoint
> for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
> longer relies on JS-interop and can safely be used in the standalone
> target. Part files that previously needed to use JS-interop have been
> moved into separate patches now, which allows us to migrate them
> incrementally.
>
> In some cases, it was easier to add new patch files:
>
> - Similar to the split between `boxed_int` and the `toString` helper
> patch, we now have the same for `boxed_double`.
> - The functionality to copy from JS typed data wrappers into Dart typed
> lists wouldn't work with standalone, so I've moved it into a separate
> method we can patch to be a noop.
> - `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
> This is part of a public API, but I had to move those declarations
> into a patch file because they wouldn't work with standalone.
> Arguably, a separate library (`dart:_wasm_js_interop`?) would be
> cleaner but it might be fine as long as `dart:_wasm` is experimental?
>
> For now, new patch files relying on JS interop are also applied to the
> standalone target. They are marked with a comment indicating that they
> need to be migrated though.
>
> Change-Id: I583f23f6cc1a3fc7332962292d69f3a7b0327409
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489660
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I21428bdabcabdbdd07f3453384bb31154083c8aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494920
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This class is structurally equivalent to _HashVMBase and the only reason
for it to exist for inability of normal Dart classes to extend
_HashVMBase - but this can worked around by properly configuring
_HashVMBase class in bootstrapping.
TEST=ci
Change-Id: I5ca401e274920d2b4739424c6b6595306a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494140
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Yesterday I discovered some code in the front end type inference
engine that I didn't expect: logic that added constraints to type
inference based on the result of applying type coercions. To figure
out why it was necessary, I disabled it and ran the code through
trybots. It turns out that it's needed to prevent the following
issues:
- https://github.com/dart-lang/sdk/issues/33298
- https://github.com/dart-lang/sdk/issues/56666
Fortunately, we had regression tests for these issues:
- `pkg/front_end/testcases/general/bug33298.dart`
- `pkg/front_end/testcases/general/issue56666.dart`
Unfortunately, those regression tests are front-end specific, meaning
we didn't have any coverage for the analyzer.
This CL adds coverage for the analyzer by replicating the regression
tests in `tests/language`.
Change-Id: Ia53b3c898549e991d6685a414d177a466a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494563
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Adds documentation of why it's necessary to feed the results of
coercions back into the type inference algorithm to generate
additional constraints.
(I was mystified by this logic, and had to try removing removing it in
order discover why it was needed.)
Change-Id: I26c40fb589e9db57deaf3dbad554353a6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494622
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The eventual goal of the `dart2wasm_standalone` platform is to not rely
on a JavaScript environment, which requires rewriting everything that
currently relies on `js_interop` or `JS()` helpers.
Since most of the patches are still written in Dart and we don't want
to duplicate that code for the standalone target, this splits patch
files by whether they rely on JS-interop or not. The main entrypoint
for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
longer relies on JS-interop and can safely be used in the standalone
target. Part files that previously needed to use JS-interop have been
moved into separate patches now, which allows us to migrate them
incrementally.
In some cases, it was easier to add new patch files:
- Similar to the split between `boxed_int` and the `toString` helper
patch, we now have the same for `boxed_double`.
- The functionality to copy from JS typed data wrappers into Dart typed
lists wouldn't work with standalone, so I've moved it into a separate
method we can patch to be a noop.
- `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
This is part of a public API, but I had to move those declarations
into a patch file because they wouldn't work with standalone.
Arguably, a separate library (`dart:_wasm_js_interop`?) would be
cleaner but it might be fine as long as `dart:_wasm` is experimental?
For now, new patch files relying on JS interop are also applied to the
standalone target. They are marked with a comment indicating that they
need to be migrated though.
Change-Id: I583f23f6cc1a3fc7332962292d69f3a7b0327409
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489660
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL changes the flow analysis slightly such that the analyzer is
able to handle a `break;`, `break L;`, `continue;`, or `continue L;`
that occurs in the body of an anonymous method. It adds a test for a few
situations where this feature is used.
Change-Id: I5b065a6ad96e346502fd071d1547ccd143f37e80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491800
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
A few minor changes:
- Log output is now written to stderr.
- `Service.controlWebServer`'s `silenceOutput` parameter is now
respected, along with the `SILENT_OBSERVATORY`, `SILENT_VM_SERVICE`,
and `SILENT_SERVICE` Dart defines.
- DDS launcher state is cleaned up if the service server is shutdown
via SIGQUIT.
Change-Id: I0e3e271905ad6bc111151bac086fe7661c23d578
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491280
Reviewed-by: Jessy Yameogo <yjessy@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
- Fixes issue where `streamListen(streamId: 'foo')` didn't result in an
error when DDS was not present.
- Adds stub for the deprecated `streamCpuSamplesWithUserTag`
Change-Id: Ic18c2b24a103347eee60ee803a873f747dbfee7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491200
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Jessy Yameogo <yjessy@google.com>
Ryan Macnak