* Parenthesize calls within `new`-expression targets to prevent the call
arguments being associated with the `new`-expression.
* Negation of exponentiation and negation as the left operand of
exponentiation are syntax errors, so parenthesize the exponentiation
or left operand.
"-2 ** n" --> "(-2) ** n" or "-(2 ** n)"
* "e in e" needs to be parenthesized in more places in a for-statement
to avoid printing a for-in statement. The missing place was the
right operand of a binary operator.
"for (i = (0 in o) || 1 in o"
-->
"for (i = (0 in o) || (1 in o)"
Bug: #54534
Bug: b/313833546
Bug: b/314023208
Bug: b/314041897
Change-Id: I12fcd75ac5546a425b21cd68a9bda3786ceb243d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347423
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
- Fixes a few spelling and grammar errors
- Standardizes formatting a bit
- Add a link to learn more about the 3.3 language change
- Adjusts wording of a few mentions to ease global understanding
Change-Id: I8755fe219f2ef12c2c89541e0e94484bf85c0bb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346601
Reviewed-by: Marya Belanger <mbelanger@google.com>
Auto-Submit: Parker Lougheed <parlough@gmail.com>
Commit-Queue: Marya Belanger <mbelanger@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This allows resolving InstanceCreationExpression(s) with constructors
added by augmentations, including for generic classes. But not all
cases of such expressions are covered by this CL, to be continued
in following CLs.
Change-Id: I7c88961b03849260999c78da21172f43923b81ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347203
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I'm not sure the history of this Extensions class, but in its
current form, it is unnecessary complexity. It is a class with a
single, final field, and a single method. The whole thing can be
inlined into the _single_ caller.
Change-Id: I3ae92383241d6f79be2d96eb52de5a7ecf661fd4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347063
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
We already have a shell script that compiles dart code to wasm and
optimizes it. I think it's rather confusing to have multiple, they
contain somewhat duplicated code as well.
We therefore remove `sdk/bin/dart2wasm{,_developer}` (which is
not used by any CI but purely for developers) in favor of
`pkg/dart2wasm/tool/compile_benchmark`.
=> It support with/without binaryen
=> It support measuring size/time/memory of dart2was & binaryen
=> It supports running compiler with assertions
Some flags/vars are not supported anymore:
* `DART_VM_OPTIONS`: Has no effect (as there's no need to support this)
* `sdk/bin/dart2wasm_developer`: Pass `--compiler-asserts` to `compile_benchmark`.
* `-O`: Optimizes now by-default, pass `--no-binaryen` to `compile_benchmark` to disable
* `-O`: Doesn't implicitly pass `--inlining-limit=10`
Change-Id: Ice656d1bfc216a536522b254e2d52bd4cad73e8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347040
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@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>
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>
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 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>
Jesse Seales