This relands a fix for looking up hostname on Windows in utf8-aware fashion.
Previously this was reverted because the API was only introduced in Windows 8,
making this use of Windows API fail on Windows 7.
With Windows 7 no longer being a target, original fix can be relanded.
BUG=https://github.com/dart-lang/sdk/issues/52701
TEST=manually
Change-Id: I330048c8b92ce805b7bb7e3fa05c88fefe3a30b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353500
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
The VM has required Vista since at least cb522bfcd2.
TEST=ci
Change-Id: I6b6d293f1e2821c441482745fef38a07aacf528c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353231
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
We don't know if there is a 'const' constructor, so we do it for all fields.
If there is no 'const' constructor, we clear 'constantInitializer's.
Change-Id: I123fe318497f074a449dae4e857889989a2563ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353230
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is a follow-up to https://dart-review.googlesource.com/c/sdk/+/350323
This CL addresses more of the cases where the `declaredNullability` of a type
object is overridden by the overall `nullability`, introducing unexpected
values to the field.
TEST=existing
Change-Id: I4830cd8113604dcc38a01ff09a9c1b2f50e091ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351141
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This looks like it was an oversight--previous to this change, there
was zero test coverage for this case.
Change-Id: I4301a3ba90aedce3b0fcd901649c370cba522f4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Currently hash code for a closure is the hash code of it's runtime type.
This causes a lot hash collisions in some apps and cause performance
issues.
With this patch we now use captured objects in closures when calculating
hash codes.
The hash codes are now:
- For tear-offs:
mix(receiver hash, closure runtime type hash)
- For instantiations:
mix(instantiated closure hash,
hashes of captured types)
Note that an instantiation can be of a tear-off, in which case
"instantiated closure hash" will calculate the tear-off hash as above.
- For others (function literals, static functions), the hash is the
identity hash.
Fixes#54912.
CoreLibraryReviewExempt: Mark private corelib function as entry-point in Wasm
Change-Id: I6a123fdc690237f543bb8bf832f0f8119d013a55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353162
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Fixes: #54971
Change-Id: I033c8ba78e6cdcf26dce9cae8998308a595a37e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353262
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
This update the checked-in SDK to a version that includes
fe52b9bfe5
which adds support for `dart:_macros` and `package:macros`.
This is needed in order to move shared macro code from to
pkg/_fe_analyzer_shared/ (a temporary location) to `dart:_macros` and
used from the CFE and analyzer through `package:macros`.
Change-Id: Icba4e19ff654b8a664269c12ac555912eccf42bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353401
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This looks like it was an oversight--previous to this change, there
was zero test coverage for this case.
Change-Id: Icba1381c389af37ab4fe38f345cc78fe6c01d7f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353226
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
If a target `_Future` is chained to another source `_Future`,
then it's because the target will complete with the same
result as the source future. Instead of keeping both
alive with a listener on the source which completes the target,
instead the target moves all its listeners to be directly on
the source, and keeps a link to the source in case more listeners
are added later.
The idea is that most futures are unreferenced after they have
had their first listener, so the target future has a chance
to be GC'ed.
If the target future has `.ignore()` called, and has no listener,
then the source completing with an error should not cause the
error to be uncaught. Without the optimization, the source would
have had a listener, and the target would ignore the error.
To simulate that, the source now gets a copy of the target's
`_ignoreUnhandledErrors` flag.
This is still not precisely the same as it would be without the
optimization. If *two* target futures are chained to the same source,
and only one of targes has `.ignore()` called, then this
implementation will make the uncaught error not be reported,
where it technically should.
(An alternative would be to *not* use chaining for futures
with `ignore()` called on them. But those are precisely futures
that are likely to be GC'able, because someone has already said
that they don't care if the future complete with errors.)
Fixes#54943
Bug: https://github.com/dart-lang/sdk/issues/54943
Change-Id: I0dbb4919ce2ea612d66539862fa0eb188aab8287
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352908
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
* Added tests for compiling the platform with coverage information
* Patched all CFE suites to be able to capture coverage information
(e.g. via
`out/ReleaseX64/dart pkg/front_end/test/fasta/strong_suite.dart \
--coverage=coverage/` and then merging and showing via
`out/ReleaseX64/dart pkg/front_end/tool/coverage_merger.dart \
--coverage=coverage/`)
* Added "meta test" that runs all of the cfe et al tests and captures
coverage information at the end.
* Patched the bulk compiler to be able to capture coverage information
(likely only works in non-Windows as it has to hook into signaling to
be able to capture data as the process is being killed by the test.py
script).
* Tool for combining the dumped coverage information.
* Meta test that executes everything and combines the result
(run via e.g. `out/ReleaseX64/dart-sdk/bin/dart \
pkg/front_end/test/run_all_coverage.dart`)
Initially I wanted to (for language tests) have per-test coverage,
changed the test.py scripts to run the tests through a special tool that
then captured coverage information for the kernel_service isolate which
worked well for tests that compiles without error, but doesn't work when
there are compile time errors (because dart terminates before coverage
can be captured). So the solution - at least for now - was to hook into
the batch compilation.
The "visualization" of the result currently isn't very good -- mostly
just a list of not covered positions -- but the hope is that everything
that should be covered (eventually) will be covered, so maybe it's not a
big deal.
Also still to do is being able to - probably via comments in the covered
code - say "this isn't expected to be covered", so we can work towards
expecting all (or certain) files to be 100% covered (modulo those
comments), e.g. when running the thing on the weekly bot.
Change-Id: I6f885f4a9c04fb52a65797a9de790e1e5eacecf1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353103
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The path separator in the expect makes it fail; shorten the path, there
is no need for a separator in the test case.
R=whesse@google.com
Change-Id: Ief6078828daa18e1bf552e62ea0d3d4dee70ec84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353400
Reviewed-by: Jonas Termansen <sortie@google.com>
Auto-Submit: Morgan :) <davidmorgan@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
This aligns this code better with Effective Dart and prepares for the
upcoming lint rule change at https://dart-review.googlesource.com/c/sdk/+/353140.
Change-Id: I4a419c50b851680150d4f17941bc0f94a98cb148
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353221
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Fixes https://github.com/dart-lang/sdk/issues/54801
Object literal constructors need to be explicitly handled when
determining a member is JS interop or not in dart2js as it does
not require any @JS annotations.
Change-Id: Iee99375439057844485aa3f5cd88f85f5d03ae06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349840
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Previously we would specify parameter offset and base register and
use SpecialParameter instruction to represent values passed in
registers.
This CL simplifies and merges these concepts: now every Parameter
instruction simply carries around its Location.
This CL also tweaks printing of stack slot locations so that they
are easier to read: `S+1` becomes `fp[1]` or `sp[1]` depending on the
base register, DS+1 becomes `dword fp[1]` / `dword sp[1]` and `QS+1`
expands to `qword fp[1]`/`qword sp[1]`.
Additionally we clean `BlockBuilder` API a bit - instead of
passing `with_frame` to `AddParameter` we make this the
property of the builder itself, set at construction time.
Issue https://github.com/dart-lang/sdk/issues/54955
Closes https://github.com/dart-lang/sdk/issues/31956
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-simarm_x64-try,vm-aot-linux-release-arm64-try,vm-aot-linux-release-simarm_x64-try,vm-ffi-qemu-linux-release-arm-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-linux-product-x64-try,vm-aot-mac-release-x64-try
Change-Id: Ie24dc6b6c47b3a45db722813218bc53c3a06c91d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353081
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This CL contains several small bug fixes:
- The context is only used for type inference if it is a record type
with the same shape as the record literal. Previously, if the
context was a record type with a different shape than the record
literal, the analyzer would attempt to do an approximate match
(using the context from any matching named fields, and from all the
positional fields that were in common between the context and the
literal). At first glance, it might seem like this would only matter
for erroneous code (since record shape mismatches typically lead to
compile-time errors). But if the context arises from a local
variable promotion, then a mismatch doesn't lead to a compile-time
error; it simply leads to a demotion. So the difference is
observable for non-erroneous code.
- If one of the fields is implicitly downcast from `dynamic`, the
static type of the field's expression remains `dynamic`. This makes
the behavior of dynamic downcasts inside field literals consistent
with all other implicit dynamic downcasts.
- If one of the fields is implicitly downcast from `dynamic`, the
downcast is made to the greatest closure of the context. Previously,
the downcast was made to the context itself, which meant that it was
possible to create static types containing the unknown type,
violating one of the key assumptions of the Dart type system.
- If one of the fields has a static type of `dynamic`, and `dynamic`
is a subtype of the greatest closure of the context (e.g. because
the context is `Object?`), no dynamic downcast is
performed. Previously, a dynamic downcast _was_ performed, meaning
that the static type of the resulting record literal would have
`dynamic` in a spot where `Object?` should be.
This brings the analyzer behavior into line with the spec and the
front end, with one minor exception:
- When the front end uses the greatest closure of the context to
implicitly downcast a field from dynamic, it uses a modified
greatest closure algorithm where covariant instances of `_` are
replaced with `dynamic` instead of `Object?`.
The front end's behavior in this rare case doesn't agree with the
spec; I'll address this in a future CL.
Change-Id: Ib1ab7ee4d0f63a152480704e2c0d5332446a613c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350983
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
NOTE: the tests view better if you turn off whitespaces on the diff.
This command will start a DTD instance that has the FileSystem service restrictions disabled. Which can be used in development environments.
Bug: https://github.com/dart-lang/sdk/issues/54762
Change-Id: I829f83d7c7afc7dd83732fc8a600cb41ffe36f63
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352921
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
Commit-Queue: Dan Chevalier <danchevalier@google.com>
This was an apparently error when moving to the SDK DAPs. The original DAPs performed 100 toStrings() (and 100 is the batch size for VS Code, so the user wouldn't usually see the limit) but we'd done 10 (actually 11) here.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4995
Change-Id: Ie3ca74c9189a725adb971646db2defaf1ffa9627
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353104
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Fix vm service tests which are racy as dds is spawned as an external
process and the testee process might have exited before dds
connects to it.
Change-Id: I514e20c84c6041cb1b65854494698911a34eb50e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352464
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
The analyzer team has decided to adopt the convention of using `TODO`
comments to document long term issues that should persist in the
codebase, and `FIXME` comments to document short term issues that need
immediate attention (see
https://dart-review.googlesource.com/c/sdk/+/295662). They may even
consider adding a presubmit hook to ensure that `FIXME` comments are
only used during local development.
We didn't consider `HACK` comments at the time, but IMHO it makes
sense to treat them the same as `FIXME` comments; that is, as a rule
we don't include them in checked in code.
This change restores the analysis server to a state of having a clean
"problems" view when edited using Visual Studio code.
Change-Id: Icd6079cb1eb47e02d9084332d0bad0e3afa04177
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353200
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This aligns this code better with Effective Dart and prepares for the
upcoming lint rule change at https://dart-review.googlesource.com/c/sdk/+/353140.
Change-Id: Ibfb4736ae01a6e2d843f9faf19eba08c16ff6c92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353222
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
PR https://github.com/dart-lang/language/pull/3560 and
https://github.com/dart-lang/language/pull/3598 updated the feature
specification of extension types to define a notion of types being
'incompatible with await'. This CL adds a test to verify that various
types are being classified correctly, and errors are hence reported
as expected for expressions of the form `await e`.
Change-Id: I39e992b4317ef49fbc2267819481d71d87b56aca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351143
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This aligns this code better with Effective Dart and prepares for the
upcoming lint rule change at https://dart-review.googlesource.com/c/sdk/+/353140.
Change-Id: I96e77d5c49c17fe0dfcbef7e997cb9d634f1e648
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353201
Reviewed-by: Ömer Ağacan <omersa@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This aligns this code better with Effective Dart and prepares for the
upcoming lint rule change at https://dart-review.googlesource.com/c/sdk/+/353140.
Change-Id: I1b3ff4a4f85ec2182d06a67acf0e43fbc45129f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353220
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
