https://dart-review.googlesource.com/c/sdk/+/346760 deleted the file
pkg/testing/test/hello_test.dart which was for whatever reason specified
in the BUILD.gn file for fuchsia builds, meaning those no longer builds.
This CL removes the reference to it, hopefully allowing it to build.
Change-Id: I51a8ae47dec61dc0bde9e0560a2cdc05cf916942
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347260
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
* It had already the assumption there's a `.` in the name but didn't
check for it
=> Validate that the output file ends with `.wasm`
* Make the unoptimized wasm (if emitted) be `.unopt.wasm`
=> It's a wasm file, so it should have a .wasm extension
This is a step towards making flutter use `dart compile wasm`
directly without the AOT snapshot of pkg/dart2wasm/bin/dart2wasm
and wasm-opt separately. Which will allow removing of the duplicated
wasm-opt flag list in flutter.
Change-Id: I685bb1aaa9d95ab43936bab68add916a642eb296
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347280
Reviewed-by: Michael Thomsen <mit@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This adds an ìsImplicitCall to DynamicInvocation which is set on
expression like `d()` where `d` has type dynamic, to distinguish
the for `d.call()`.
TEST=pkg/front_end/testcases/general/dynamic_call.dart
Change-Id: I73beb911bdb315a510c862e6d4876cf7673ec3c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346240
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Golem build configuration is setup in a way that includes the `pkg/`
folder entirely, so the shell scripts should have access to the
`dart compile exe` sources.
Change-Id: I5395413ce85f11098d14eacbd6ce392f665ddce5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347021
Reviewed-by: Slava Egorov <vegorov@google.com>
These prints were accidentally included in
https://dart-review.googlesource.com/c/sdk/+/345827, causing all runs
of `dart analyze` to output the communication with the analysis server
to standard output.
Change-Id: I6610ccc9d4b091d85809f8557daf6b96497d1c9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347067
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
It looks that the element model correct, but resolution is not yet.
I will work on improving resolution in following CLs.
Change-Id: I225db07bf243539638364b711f0c9c68550199f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347120
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This adds support for serving the contents of virtual files to the client over a custom LSP protocol (based on the VS Code API of the same name). This is currently a custom Dart protocol but hopefully very close to something that could become standard LSP in future.
If the client advertises support for this feature (currently with an experimental flag "supportsDartTextDocumentContentProviderEXP1") we will return the set of URI schemes we can provide content for (currently "dart-macro-file"). Additionally, we will map internal analyzer macro paths (like `/foo/bar.macro.dart`) onto that scheme (`dart-macro-file://foo/bar.dart`) instead of standard `file://` URIs.
Overlays are not created for these kinds of files (because they would override the server-generated content).
Some language functionality "just works" because we can get resolved ASTs for the macro files (and many LSP features operate on these), but more testing (and tests) are required.
Included are tests for the virtual file methods (and events) and Go-to-Definition. Tests for other features are outstanding.
Change-Id: I2056699652873a12b730f565b823f187f883a1ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345420
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This also simplifies the logic of determining whether a possible producer is
already being proposed as a quick fix for an enable lint rule.
Fixes testing analysis_server with: `dart --enable-asserts pkg/analysis_server/test/test_all.dart`.
Otherwise a functional no-op.
Change-Id: I623101b1c4c732f631a0b74c488cc8853afd282e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346622
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This test appears to have been flaky for a while. Sometimes the analysis status triggers multiple times during the test run which results in "Future already completed" errors.
It's not clear why the status fires multiple times (I cannot reproduce it locally despite running in a loop for a while) but the test really only cares about detecting that initial analysis has completed, so I've changed it only track the first instance.
Change-Id: If8e5d5b3ba27217bbdce94a68840882773920351
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347020
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This is can happen if a Dart or Flutter application is started in a
non-standard way (e.g., not through the `dart` or `flutter` CLI
tooling). Developers using custom embedders need to use `dart devtools`
to start a DevTools instance, so it's a good opportunity to check for a
DDS instance and launch DDS for the target application if one isn't
found.
Change-Id: I817ca0951c7839e8e9a0d1c78756caa45381cea1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346820
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The front end and analyzer use the same representation for types and
type schemas, with the unknown type schema (`_`) treated as a
pseudo-type. This creates the risk of accidentally mixing types and
schemas, resulting in `_` accidentally "leaking" into the type system
and showing up in static analysis results or error messages.
As a step toward reducing this risk, this change adds a type parameter
to `TypeAnalyzer`, preventing the shared type analysis code from being
able to assume that types and schemas are represented the same. This
extra discipline makes it much easier to search through the code and
identify how types are manipulated vs. how type schemas are
manipulated, and makes it impossible for the shared type analysis to
accidentally leak `_` into the type system.
I believe this change will also make it easier to implement some type
inference improvements we've been contemplating, such as improved type
inference of `.map(...).toList()`, as well as
https://github.com/dart-lang/language/issues/3471, because those
improvements may require introducing new kinds of type schemas.
Change-Id: Ifcd7e2c4e1172ee39719ce8c8b10d7f10f6a7b6f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345353
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
A line marked with "// error" should get an error (or it's an error),
and one marked with "// ok" should not get an error (and if it does it's
an error).
Some tests are left unhandled and are programatically ignored in this
first CL. A bug (https://github.com/dart-lang/sdk/issues/54635) has
been filed to sort those out.
Change-Id: I083f62829ceff6ff85121e21cfdb6670bfacb7e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346301
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This is a reland of commit 66d3eedb33
g3 breakage was fixed in https://dart-review.googlesource.com/c/sdk/+/346940.
Original change's description:
> [vm/aot/tfa] Analyze function calls
>
> This change adds analysis of function calls when closure target
> of a call can be inferred. Local functions are now analyzed separately
> from enclosing members. Inferred result type of function calls is now
> used in the AOT compiler.
>
> Time of AOT compilation step 2 (TFA) on a large Flutter application:
> Before: 59.448s
> After: 61.870s (+4%)
>
> Maintaining hierarchy of function types and analysis of all function
> calls is not feasible as it causes unbearable increase in AOT
> compilation time.
TEST=existing
Issue: https://github.com/dart-lang/sdk/issues/39692
> Change-Id: Ieb4d5dce23868b5ab5c87fa1e77e49b85fd656fe
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345083
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
Change-Id: I05377121ffa7e56748c8a5ab58551e2b1caef70b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346946
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This should fix analyzer-mac-release bot.
Change-Id: Ia61f5c33a21d703f20fb7a275bbffa4511a122c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346941
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Also, fix a bug with the associated file.
Change-Id: Ib8440e0ce6846ed664a836227ea0ab3a841dcdc1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346942
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This change fixes the following 2 bugs related to unwinding records
on Windows:
1) When cross-compiling from another OS to Windows, unwinding records
were not added to the end of the code section. Later, when loading
AOT snapshot, arbitrary bytes at the end of the code section were
used as the unwinding data, which could result in the errors
returned from Windows API calls.
2) When code section is mapped, its size was rounded up to the page
size; when looking for unwinding record, size of the unwinding
record was subtracted from the rounded size. This is not correct
as unwinding record is placed right at the end of code section,
so code section size should be used before rounding.
Also, magic value is added to the unwinding record in order to
verify that it is preserved and correctly found.
TEST=Manually tested repro from b/320642692
TEST=ffi/ffi_induce_a_crash_test
Fixes b/320642692
Fixes https://github.com/dart-lang/sdk/issues/54206
Change-Id: Id0c6413cd1b759da9e9f25f7617eef55f33b04a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346940
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
I discovered recently that when we implemented the "patterns" feature,
we got the pattern type schema for cast patterns wrong--it was
specified to be `_`, but what was actually implemented was
`Object?`. I've filed a breaking change request to address that:
https://github.com/dart-lang/sdk/issues/54640.
In the course of prototyping a fix, I was surprised to find that no
language tests or co19 tests were affected; it appears that we don't
have adequate test coverage of pattern type schemas. This CL addresses
the lack of test coverage by adding a language test.
The test case for cast patterns is currently commented out, pending
resolution of the breaking change request; after the breaking change
lands, I will update the test accordingly.
Change-Id: I0d27fd8ac65f16d21a8597586e6f76fd9a5ba86e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346621
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
