This adds a DDC frontend server test that shows DDC doesn't currently
support advanced invalidation.
Change-Id: Ie6176bc4fa9d91262c0a6e0a30a1fccee96023be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252424
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
There were no changes other than to move the files and update the imports
to match.
Change-Id: I0790d9bf7287d62756ad7534b760689489706d40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253602
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Customers have started using the cherry-pick template to input
feature requests and bug reports. This CL moves the standard issue
template to the top level so it is the first item contributors see when
creating a new issue.
moved original templates
reordered issue templates
Change-Id: I78586c8dc6de673a7ee4d49afe88ce28703b60e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253522
Commit-Queue: Kevin Chisholm <kevinjchisholm@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
A FieldEntity is used as the entity for generating the setter of an
instance field (when a check is required), and as the entity for the
initializer expression for a static or top-level field.
I think it is a bit clearer to have a separate method for each case
rather than one method with conditional paths.
Change-Id: I32e63c3f3566a63e3d38315cab17d613f006405e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253562
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
The scripts originate from Chromium, this CL syncs Dart's copy with Chromium tip of the tree at 6f8f710079b3e363f4fd7ffe3d848384e4b7c816.
Format toolchain/win/BUILD.gn
Change-Id: Ice7ba48bdd102ffe0e25c6ae6068f83cb14169ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253500
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This change removes duplicate management of inputs in variadic
IL instructions by introducing VariadicDefinition and
VariadicDefinitionWithEmbeddedInputs base classes.
TemplateInstruction and TemplateDefinition are used in more
places where appropriate.
Number of inputs no longer depends on the values of the inputs
(DropTempsInstr and AllocateObjectInstr).
This change also prepares IL for the future implementation of binary
serialization/deserialization in the following ways:
* Environment now holds Function and not ParsedFunction
(which are not going to be serialized).
* Instructions no longer keep Zone* pointer (it's redundant).
* NativeCallInstr keeps references to handles instead of pointers.
TEST=ci (pure refactoring)
Change-Id: I932b62c1c207bbf60cddbded8a39b41beabd3e83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253480
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This is a reland of commit cc9d14d822
TEST=vm/dart{,_2}/causal_stacks/async_throws_stack_lazy_non_symbolic_test
Original change's description:
> [vm] Remove warnings about non-standard stack traces.
>
> The language team has clarified in
> https://github.com/dart-lang/language/issues/1212 that the content of
> stack traces is not specified in a way that is violated by either
> obfuscation or non-symbolic stack traces. Thus, we remove the warnings
> about supposedly standard-violating stack traces.
>
> TEST=No change in actual functionality, so tested manually.
>
> Bug: https://github.com/dart-lang/sdk/issues/43388
> Change-Id: I2c7ac44cf2f9afafa85d902b2783e1173e727264
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249185
> Commit-Queue: Tess Strickland <sstrickl@google.com>
> Reviewed-by: Daco Harkes <dacoharkes@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Bug: https://github.com/dart-lang/sdk/issues/43388
Change-Id: I2f99779e391b156ca963be57467b40dbe69f2b76
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253281
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
When launched as a snapshot, the initial compile is slower than the existing pub approach because of a process start time of around 500 ms. When launched as a compiled executable, initial compile times are the same as the existing pub approach. Once launched, experimental results show times to produce a kernel file of at worst 1.5-2x faster than pub's solution and at best 10x faster than pub's solution. The typical workflow of making changes and recompiling results in an average of a 5x speedup with respect to pub's implementation.
Because compiler instances use a lot of memory, there is a limit on the number of active compilers that the resident server will keep alive, and will actively bring instances down when this limit is exceeded. If the user was previously compiling a given project during the lifespan of a ResidentFrontendServer and its compiler is taken down between requests, a new compiler instance will be allocated for the request. Performance is still between 1.5x-5x faster for this case when compared to pub's compile times.
Change-Id: If9ee1ecc71d660d34faf23381c764dc11d6a5902
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252001
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Michael Richards <msrichards@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Support for optionally dumping linking between properties and accessors
in element model tests.
Bug: https://github.com/dart-lang/sdk/issues/49547
Change-Id: Idb195213f5812b8b3d68f0dd857e06c889a3e076
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This reverts commit a5fda59219.
Reason for revert: breaks calling extension setters with `?.`, see b/241059207
Original change's description:
> [cfe] Use `void` for let-expressions for extension property set
>
> This pipes the expression type for a generated property setter, such
> that synthesized variables in let expressions created for the generated
> setter expression are typed correctly.
>
> Before this change a let variable created for an extension property set
> would use the value type even though the extension property setter is
> method with a void return type.
>
> Change-Id: I1e7d31eaf1410bb06d55e2845403865e0c7af452
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252742
> Commit-Queue: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
TBR=johnniwinther@google.com,askesc@google.com
Change-Id: Iaafd12833939cbd38e09787fcdb5a4c78a964656
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253440
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Ilya Yanok <yanok@google.com>
This pipes the expression type for a generated property setter, such
that synthesized variables in let expressions created for the generated
setter expression are typed correctly.
Before this change a let variable created for an extension property set
would use the value type even though the extension property setter is
method with a void return type.
Change-Id: I1e7d31eaf1410bb06d55e2845403865e0c7af452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252742
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
getter and setter methods also take a receiver argument, treat them the
same way as non-static methods
Fixes#49563
Bug: 49563
Change-Id: I778e0dc18e5e2e10cf689b171fac4030b104ca2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252941
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
It was assigning a List<String> to List<String?> which is allowed due
to (unsound) covariance but would then fail at runtime when null was
assigned to a list element.
Change-Id: Ia893998e8866067b54cfa354b9c4e13d76b6d9ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253303
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
always_declare_return_types
unawaited_futures
Enabled, fixed then disabled directives_ordering due to code generation
Change-Id: Icaf7358222b1c9a939a4764be091e1956d449386
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253365
Commit-Queue: Mark Zhou <markzipan@google.com>
Auto-Submit: Kevin Moore <kevmoo@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Invocations of the spec parser used to exit with an error code (245)
in the case where no files were specified. This was considered to be a
useless type of invocation, and the spec parser would print out a help
message.
However, it is perfectly possible for a Gerrit CL to give rise to
invocations like that, e.g., when the CL deletes some files and does
nothing else. Also, it causes no known issues to report a success exit
code (0) in the case where no files are specified, and hence this CL
changes the spec parser accordingly.
Change-Id: I9bd75839f1a8052b3daa62fa5440451e46fb59e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253280
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Deletes the outline stubber as it's not necessary on any backend.
DDC should compile the entire sources and outline dill in one step.
dart2wasm operates similarly, and so only needs the modular transformer.
dart2js moves the erasure to a global transform.
Also, this CL reverts now unnecessary plumbing that was needed for the
outline stubber.
Change-Id: Ic085c4fad5a6bdfc7d6916f7fa575c6ef9b20110
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253000
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The resolution of the redirecting factories should happen after the
type inference because the inference needs the original, unresolved,
representation of the program. Some areas of the CFE attempt to finish
the delayed computations, including the resolution of the redirecing
factories, before the inference phase. An example of such area is the
enum member generation. It has to happen early for proper scope
construction. At this stage we know that we can delay the resolution
of the redirecting factory invocations becuause it will be attempted a
second time later, after the inference is done.
Closes https://github.com/dart-lang/sdk/issues/49429
Change-Id: I65c1f903ce2783580785cd1ad61291c28a924937
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252943
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
