This reverts commit a356f71b71.
Reason for revert: This should be handled by throwing an exception when
the methods of the returned window are called, not when it is opened.
This would be a noisy breaking change that we don't want for 3.1. For
now, revert until the change that affects the individual methods is
landed.
Original change's description:
> [dart:html] Throw exception if Window.open opens null window
>
> Window.open silently allows a null window to be opened, and
> issues arise later when users try to use the non-null wrapper.
> This CL changes that to throw an exception if the window is null.
> This exception can be caught and recovered from. This avoids the
> larger breaking change of making this API nullable.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I9a53a477cb370c3bc6bc26b2162ce66c5af166aa
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306910
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
CoreLibraryReviewExempt: Revert in backend-specific library.
Change-Id: I5007b7d7aa608bfc8e5827b5f967af5573d0b758
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309000
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This reverts commit 14a3051552.
Reason for revert: b/289195983
Original change's description:
> [dart:html] Move NullWindowException to implementation
>
> Window.open may open a null window in more cases than expected.
> Users may not care that the window they get back is invalid if
> they never use it. Therefore, this CL moves the exception to
> the implementation of the returned window in order to reduce
> noise, but still give a way for users to recover if they wish
> to do so.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I005cf80630cfb4db2f5ec2012cfcd0161ad10ff1
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311460
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: Id7c514a80fdcaa18a7eb0acdcb7f36477a04d966
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311843
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
Handle::data_ready_ contains bytes which are ready to be sent to Dart
side. Not all code paths fully drain this buffer and delete it
before destroying the handle, for example directory watch implementation
was prone to leaking data_ready_ when subscription was cancelled.
This CL switches the code to use unique_ptr to hold on to data_ready_
which makes sure that it is deleted when Handle is destroyed.
The code would benefit from holding all OverlappedBuffer instances
through unique_ptr but that is a much larger refactoring which
we leave for a later date.
Fixes https://github.com/dart-lang/sdk/issues/52715
TEST=standalone{,_2}/regress_52715_test
Bug: 52715
Cq-Include-Trybots: luci.dart.try:vm-win-release-x64-try,vm-win-debug-x64-try,vm-aot-win-release-x64-try,analyzer-win-release-try
Change-Id: Ie8d728b823de7e8f9de1489898e270580c2af269
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311841
Commit-Queue: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Slava Egorov <vegorov@google.com>
When Isolate is just starting up and no TLABs are yet present
we were setting interval_to_next_sample_ to -1 which caused
every old space allocation to be sampled.
This CL properly initializes the interval to sampling_interval_
instead.
TEST=vm/cc/DartAPI_HeapSampling_CorrectSamplingIntervalForOldSpaceAllocations
Change-Id: Ieb29234379d3afa4716ebdf3591f9fc0cbcaef71
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311844
Commit-Queue: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Auto-Submit: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Root cause is that `Function::Hash()` depends on the owner class
id. This causes two issues
a) Issue with reload:
During reload the reloader code will change `Function::owner()`
from a `Class` to a `PatchClass`. This in return will cause a change in
the function's hash, which means we won't find the function in the
closure cache anymore.
b) Issue with app-jit:
As part of app-jit we re-number class ids. This re-numbering would also
render the closure cache as invalid - as the function hash code would
change. So instead the closure cache was cleared entirely. While this
works for AOT, in app-jit we may serialize closure functions and their
code. Though at app-jit runtime we then fail to find the functions in
the closure function cache (as it was cleared during snapshoting)
(This will surface by us triggering an optimizing compile of a function
in the background compiler which will try to make a new `Function`
object for a closure, even though the app-jit snapshot already has one)
To fix these issues we make the `Function::Hash()` stable across reload
* we use `Function::Owner()` instead of `Function::owner()` (the
former will always return the actual class, the ladder can return
the `PatchClass`)
* we avoid re-hashing the closure cache by making `Function::Hash()`
use the name of the class instead of the class id
* we clear out the closure cache array during AOT snapshoting, as this
is not used in AOT runtime.
Closes https://github.com/dart-lang/sdk/issues/52803
TEST=Fixes various issues on CI.
Change-Id: I352d0a768df0f29d504cdd80e3533cbedc437b9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311744
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This adds FileUriConstantExpression, a subclass of ConstantExpression, to support correct file offset of annotations for augmentations and patches.
The FileUriExpression is used to carry the file uri of the expression
before constant evaluation.
TEST=general/patch_annotations
Change-Id: I0dc8a0cb97dd530fd1960785d38c2d5e4883c3dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311660
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
More details about the design:
https://docs.google.com/document/d/1QDjyY_6wOTOgURwpeYMKU9qEz0gKxx2MUrdruC6Kp6c/edit?usp=sharing
Change-Id: Ie3985d86dca7f5010044ca46c33ca177588c0f69
Bug: #37022
CoreLibraryReviewExempt: Reviewed by vm and api groups. web and wasm groups not affected because FFI isn't on those platforms.
TEST=async_void_function_callbacks_test.dart, ffi_callback_metadata_test.cc, other front end tests
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305900
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Hashes of functions depend on the class ids, so cache of the closure
functions should be cleared when class ids are sorted.
This is safe to do because at that point all compiled code is cleared.
TEST=ci
Change-Id: Iaf3a66d1026611fc0a3df3903cb4e09e6d6c4c17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311723
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Previously, inliner was able to inline closure calls only when closure
was allocated in the current function (or in a function which was
inlined so far). This is not true for local functions declared in outer
functions (they are allocated at declaration site).
Now, when calling local functions, target of closure call is always
known regardless of where the function is declared, so calls to local
functions can be inlined.
TEST=runtime/tests/vm/dart/inline_local_functions_il_test.dart
Fixes https://github.com/dart-lang/sdk/issues/52695
Fixes https://github.com/dart-lang/sdk/issues/15558
Change-Id: I0e51dbaf63a6d4427bff366b40414ca5fac3d418
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311465
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Closes#31670
In `add` and `addStream` mention that int values which are too large are
truncated to bytes.
R=lrn@google.com
Change-Id: Idf276fc65592e21766659e9d89dd687c441b7357
CoreLibraryReviewExempt: Doc changes only.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310768
Auto-Submit: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
'document.body' is not defined on the d8 platform but 'document' is so this was throwing.
Change-Id: I6e4049d86beedf4dbadee466fa581e4d3426df41
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311560
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
In order to have the browser send a new request for each retry (each new appended script tag), a query token must be appended to the URI. We don't include any extra tokens on the initial request.
Change-Id: I846660894c16345a441193cd9c7b4784364a3c54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311200
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
These checks convert what would likely be a segfault into a breakpoint
instead, but they're heavyweight enough on certain tests to cause
timeouts. Remove them as issues here are easily debugged without them.
Fixes https://github.com/dart-lang/sdk/issues/52787
TEST=vm/dart/regress_48523 on debug reload bots
Change-Id: Icf9ea6191eb82c254d9a01fbc9f8ba6255602084
Cq-Include-Trybots: luci.dart.try:vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311621
Auto-Submit: Tess Strickland <sstrickl@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
E.g. if asking the tool to figure out any performance changes to
revision 5222bfd90c it will checkout 5222bfd90c and 2037563b94
(the previous commit), make aot-snapshots for both and run both on
the same (specified) target.
Change-Id: Ief56843326343ebaa681df596162d1d08457a8f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311602
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When there are multiple isolates, we may get breakpoint responses/events like this:
- Request/Response to add breakpoint to Isolate 1
- Request/Response to add breakpoint to Isolate 2
- BreakpointAdded for Isolate 1
- BreakpointResolved for Isolate 1
- BreakpointAdded for Isolate 2
Because Isolate 2 did not load the script, the last breakpoint was never resolved. However because the breakpoint ID matched, we would forward this event to the client and un-resolve the previously resolved breakpoint. This would result in odd behaviour in VS Code.
Additionally, the VM may return the same BM breakpoint ID for what the client thinks are two breakpoints (they are on different lines, but resolve to the same location) so when we get a resolved breakpoint, we need to handle both:
- Client breakpoints that have already been transmitted
- Future client breakpoints that may resolve to this same VM breakpoint
The previous code assumed that a BreakpointResolved event could be handled just once. Either for an existing breakpoint, or a future one.
This change swaps from storing queued events to storing the resolution information for each breakpoint, and it does this even if there was an existing breakpoint (in case the breakpoint is reused in future).
Fixes at least some of https://github.com/Dart-Code/Dart-Code/issues/4598
Change-Id: I53b92debfaa0c8f538dc8d67966854bb89634708
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311480
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
It's been skirting the Pass/Timeout border for a while now, but has
finally become consistently Timeout.
Issue: https://github.com/dart-lang/sdk/issues/50421
Change-Id: I922fbb55b5a48f57f8071597e8082a12a0883331
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311640
Commit-Queue: Tess Strickland <sstrickl@google.com>
Auto-Submit: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The main difference from the previous harness is that it
allows auto updating the expectations instead of
maintaining them manually.
This relands 0c1b2722ed with
changes to harness which fix issues on Windows.
Note: some amount of AOT failures are expected and should just
be approved. They will be fixed with the last CL in the series.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-win-release-x64-try
Change-Id: I7ae84769ed54bc447ebf71acc68ba9d0b6717bac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311604
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Auto-Submit: Slava Egorov <vegorov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
It was looking for gomacc in .cipd_bin but it should have
been looking for gomacc.exe
Change-Id: Idec9eb956513ad39a2d0b0b51aa39da063c75e25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311601
Auto-Submit: Slava Egorov <vegorov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
This reverts commit 0c1b2722ed.
Reason for revert: Failures on AOT (stack expectations unmet) and Windows (parse errors due to Windows paths) trybots.
Original change's description:
> [vm] Rename tests causal_stacks -> awaiter_stacks and improve harness.
>
> The main difference from the previous harness is that it
> allows auto updating the expectations instead of
> maintaining them manually.
>
> TEST=ci
>
> Change-Id: I80e303d3ecbcc834ac94fa089cabe4f8834cc661
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311400
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Commit-Queue: Slava Egorov <vegorov@google.com>
Change-Id: I7311bf08403f4167f88f6204fde1a6fdee353f7d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311600
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The main difference from the previous harness is that it
allows auto updating the expectations instead of
maintaining them manually.
TEST=ci
Change-Id: I80e303d3ecbcc834ac94fa089cabe4f8834cc661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311400
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The name is more accurately reflects what this stack trace
contains: despite what causal implies it does *not* actually
reflect the stack which initiated the async operation. Instead
it contains the chain of listeners which will run when
the async operation completes - its awaiters.
TEST=ci
Change-Id: Ie7309c9b1c39246e0fd4c14f7b9c515bcdfbbe10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311384
Reviewed-by: Derek Xu <derekx@google.com>
No need to pass parameter explicitly because it is always
equal to the field.
TEST=ci
Change-Id: I04d86786d5278ad4ab4ce6c67e61b1fc94f692d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311383
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Effectively it is true for all environments where
debugger is actually present.
TEST=service tests
Change-Id: I0592e83004271ca32c107f4347f7bd82172b0a62
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310622
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
