First stab at loading named configuration, plus temporary test code
Change-Id: I5835fe34a024a6052021c8189629a1578bed2355
Reviewed-on: https://dart-review.googlesource.com/63880
Reviewed-by: Bob Nystrom <rnystrom@google.com>
We need to clarify the following case:
`dynamic foo() => print('');`,
`dynamic bar() { return print(''); }`
that is, using `return e` where `e` has type `void`, when the return
type of the enclosing function is `dynamic` (inferred or explicit).
We do not currently have any elements in the generalized-void.md
whitelist for that, so it's an error. However, invalid_returns.md
from https://dart-review.googlesource.com/c/sdk/+/60401 implies
(patchset 6: line 19-20 and 34-35) that it is allowed.
It is my impression that we agree on invalid_returns.md, and also
that it describes the current behavior (maybe not 100%?).
This indicates to me that we should, probably, add an element to
the above-mentioned whitelist to allow it.
This CL makes that change to generalized-void.md.
Change-Id: I0326081960deda907b3b4ff34bd2d60f7c9dc35b
Reviewed-on: https://dart-review.googlesource.com/64341
Reviewed-by: Erik Ernst <eernst@google.com>
The issue was raised recently that there must be generated forwarders
for some method signatures that we had not previously mentioned in
nosuchmethod-forwarders.md: Private methods with an inaccessible name,
that is, private methods declared in a different library than the
current target of nSM forwarder generation.
Given that such forwarders are semantically significant (a tear-off
performed in the library where the abstract private method declaration
is located would tear off a generated forwarder, rather than causing
an invocation of `noSuchMethod`), we need to specify this.
This CL adds such a specification to nosuchmethod-forwarders.md.
This CL addresses SDK issue #33725, and SDK issue #33727 is related
being concerned with the implementation in the common front
end.
Change-Id: Iedbcdd8b4c8df95c6038022f72b3211ec1b76649
Reviewed-on: https://dart-review.googlesource.com/64380
Reviewed-by: Erik Ernst <eernst@google.com>
Fix up override_inheritance_method_test.dart
Fix up override_inheritance_generic_test.dart
Fix up override_inheritance_field_test.dart
Fix up override_field_test.dart
Change-Id: I09f88c18e2473be645a955e1dc63d788e61382f4
Reviewed-on: https://dart-review.googlesource.com/64682
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Change-Id: I1251c94e87fe6953f7604b5ef8f6ae5c49ab36d3
Reviewed-on: https://dart-review.googlesource.com/67522
Commit-Queue: William Hesse <whesse@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
1a122e3ac0 looks like it accidentally stopped providing summaries at all in analyzer mode, and didn't take into account the summary extension when doing automatic module renaming.
Change-Id: Ib08d0ed169670d704a87d53d1937495939db9a73
Reviewed-on: https://dart-review.googlesource.com/67684
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This starts tracking inlining data and records it as an extension
to source-map files so we are able to expand inlined calls when
deobfuscating production stack traces.
Change-Id: I46daf21c2f42305b2bd6ca17fbafb65226355096
Reviewed-on: https://dart-review.googlesource.com/67083
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Currently, the VM can create depfiles when writing out a snapshot.
The snapshot file is the output file for the depfile. This change
allows creating a depfile when not writing out a snapshot. It
accomplishes this by adding a new flag --depfile_output_filename,
which allows the user to supply the output filename for the depfile,
which would otherwise be ambiguous when we are not creating a snapshot.
This change also adds the flag --depfile, which
--snapshot_depfile is now an alias of.
related #34026
Change-Id: I45eee463c499fc542e577d805b7ef9911ccb72a7
Reviewed-on: https://dart-review.googlesource.com/67420
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Also, a few methods (needed for bytecode compiler) moved from
FlowGraphBuilder to BaseFlowGraphBuilder
Change-Id: Ibee87e6d5fdc8143786fd41763a9fd4897d06cba
Reviewed-on: https://dart-review.googlesource.com/67504
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
It's currently just passed around and never used, so remove it for
now. We will (obviously) restore it when and if we need it.
Change-Id: Ie47243f73d74190c2acf4c6f83eb2fa6f60702fd
Reviewed-on: https://dart-review.googlesource.com/67560
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Convert bytecode indices to pc offsets when reading bytecode exception tables.
Print pc descriptors and exception handlers in bytecode disassembly.
Propagate unhandled exceptions after calling interpreter.
Change-Id: Idb3b5459165ab0a124877452b1d9865d27c06d56
Reviewed-on: https://dart-review.googlesource.com/67501
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
The timeout was increased in:
d6519499fe
to compensate for not running the kernel isolate from an app-jit.
Tests are still timing out on the debug bot, so this CL will see if
increasing the timeout there helps.
Change-Id: I71656b9b6bf5c23af68d00e288d8cddc415dd102
Reviewed-on: https://dart-review.googlesource.com/67482
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
related #34030
Change-Id: I5806294d38d2c28aa80f6e1292dbf28b7774b0d0
Reviewed-on: https://dart-review.googlesource.com/67480
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
This fixes 18 language_2 tests.
Small degradation in Analyzer unit tests is cause by the way we apply
Kernel type to Analyzer type annotations in DeclarationResolver. We
should shift this logic to using store type resolution instead.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I2d60201ec4f4a741bba3f86f65d8dc3b6547514c
Reviewed-on: https://dart-review.googlesource.com/67260
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
We don't actially need them, while formally interface of
ConstructorInvocation.getStaticType() requires it, but this node
does not use it.
This solves one of the reasons why we have memory leak during
incremental analysis with CFE.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I74aa6302a463f5f15d1934f5aea49570d6140b3e
Reviewed-on: https://dart-review.googlesource.com/67382
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
