You can't use it in a way that would require Phi in the SSA form
because SSA construction does not support generating phi-functions
for the expression stack.
Change-Id: I57a029412cbdd796ecfd3cdbd0ec68e0dbca2356
Reviewed-on: https://dart-review.googlesource.com/47740
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When incrementally compiling, we can have builders for things that aren't
included anymore. Such builders should not introduce errors.
Change-Id: Ia0487d84819028913d54f6b55a2882e620009bd9
Reviewed-on: https://dart-review.googlesource.com/47223
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this CL, if loading a library from the dill file what ends
up being unused in the new program it would still be included in the
output. This CL introduces a test and fixes the problem.
Change-Id: I60dd9c3b6bdb959e103f0d2a5653d036b6653140
Reviewed-on: https://dart-review.googlesource.com/46983
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this CL, if incrementally compiling something and the .packages
file changed we could get a crash when trying to translate a package url.
This CL introduces a test and fixes the problem.
Change-Id: Ie1874780df7ade394eecef05835b0d9203f4c2b5
Reviewed-on: https://dart-review.googlesource.com/46982
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Split into 2:
- One with a "smoke-test" of dart2js.
- One with several small examples that has caused problems in the past.
The latter of the two is now based on package:testing and the test-cases
are saved as yaml files.
Change-Id: I8b588e9b42edc73f58a07292a1226e37cc458d89
Reviewed-on: https://dart-review.googlesource.com/45505
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before this CL, mixing something in that was a part of the sdk would,
when initializing from dill, cause the source of the file from the sdk
that contains the mixed in class to be included in the output.
This CL fixes that.
Change-Id: I041071844f90170ad2abeafca0b7e1596e8aa77b
Reviewed-on: https://dart-review.googlesource.com/45260
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL adds a test, where compiling without initializing from a dill
file and compiling with initializing from a dill file produces different
results in non-strong mode.
In the test the result is either
`method foo(tes2::B<dynamic> cls) → void {}`
or
`method foo(tes2::B<core::String> cls) → void {}`
Change-Id: I6fed33ba92c933c3cd17e292e2ade348357c3689
Reviewed-on: https://dart-review.googlesource.com/45500
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This section will be used later to override whether a configuration specific
condition is supported for a given platform library.
Change-Id: Ia77607060273dbd6e106ae9b14ee626a4f077d45
Reviewed-on: https://dart-review.googlesource.com/47402
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This CL extracts recovery for invalid library names into a new
subclass of IdentifierContext. This same approach will be used in
subsequent CLs to improve error messages and recovery when parsing
identifiers in other situations.
Change-Id: I03987f4e4bbe0f61f88adb3028a87e41d7dc7eb3
Reviewed-on: https://dart-review.googlesource.com/47541
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Change-Id: I79e86ef8681b0b169b0b40da26a5834eaace66a3
Reviewed-on: https://dart-review.googlesource.com/47580
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
This reverts commit ae130bc187.
Reason for revert: snprintf doesn't like positional format strings on Windows.
Original change's description:
> [ VM / Dart 2 ] Fixed StackTraceFormat test to expect file URIs in stacks generated by the Dart frontend.
>
> Change-Id: I26f09e094e934485575e55a6a60a8fccfbd94aa7
> Reviewed-on: https://dart-review.googlesource.com/47520
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,zra@google.com,asiva@google.com
Change-Id: Idbc15d59bcc7ff3534010f6c93cebdcc89c935fc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/47640
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Bug: dartbug.com/32632
Change-Id: I26acd8e01b776719f4592683eaf56ca3d3fcf72c
Reviewed-on: https://dart-review.googlesource.com/47600
Reviewed-by: Alexander Thomas <athom@google.com>
related #32619
Change-Id: I0fc20f21cf3a6e231e0f3d962f139fd072acf3ab
Reviewed-on: https://dart-review.googlesource.com/47540
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
The source-based pipeline was simply iterating the token script of a
[Script] to generate a list of (line, [token positions]) tuples.
The kernel-based pipeline is not based on the source (and therefore also
not based on the token stream). Instead it's based on information from
two places:
a) The .dill file constains a delta-encoded list of line start file
offsets. This line starts array is attached to [Script] objects via
[RawScript.line_starts_].
b) It scans the *entire* isolate's program structure (i.e. libraries,
classes, functions and fields) and does abstract interpretation
of the kernel blob (ast) and saves the encountered token positions
on the side. Afterwards the token positions are merged together
with the line-starts from a) which then produces the list of (line,
token positions) tuples.
This CL changes b) to only do the abstract interpretation of
functions/fields which are relevant for the [Script] we are generating
the list of (line, [token position]) tuples for.
Nonetheless, b) will still iterate over the entire isolate's program
structure to find all possible elements belonging to a specific
[Script]. This is a separate issue which should be handled.
On one example it reduces time to get the coverage from ~ 35 seconds to 9.5
seconds (baseline from dart-v1 is around 6.5 seconds).
Issue https://github.com/dart-lang/sdk/issues/32562
Change-Id: I64cda28666c732938379cdf4b2ac62a2371cb3b7
Reviewed-on: https://dart-review.googlesource.com/47080
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
In response to redness for the dartanalyzer after landing
7c05f1e608.
Change-Id: I9fdc606fd30e43144d3f75d67b42820c1e7c0487
Reviewed-on: https://dart-review.googlesource.com/47460
Reviewed-by: Erik Ernst <eernst@google.com>
Change-Id: I53a569eeee04f54fe2ac55009a25a806356d9880
Reviewed-on: https://dart-review.googlesource.com/36440
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
These are starting to cause problems than gain since the old frontend
isn't updated to handle new type semantics.
Change-Id: Ib8d92e5ee0c5efd4837abe2b52177960ffbb115f
Reviewed-on: https://dart-review.googlesource.com/46981
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Since the kernel reading helpers have been extended to not only work
with a kernel blob in C heap, but also work based on a [TypedData]
buffer in the VM heap, access to the [TypedData] buffer is on the hot
path now.
This hot path is slowing things down considerably, in particular due
to NoSafepoingScope's.
This CL removes a critical NoSafepoingScope when accessing the
[TypedData] in read-only mode. It also allows passing in the [Thread]
directly, to avoid TLS lookups.
Issue https://github.com/dart-lang/sdk/issues/32603
Change-Id: I91955bea5cd4eddbbd21c5d3bc6813504c2cece9
Reviewed-on: https://dart-review.googlesource.com/47222
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
related #32619
Change-Id: Iee23ea5d80f398e7a25b4c77164f327c4cf064ab
Reviewed-on: https://dart-review.googlesource.com/47401
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
During SSA construction in strong mode, types of local variables are
propagated (assigned) to phis which are 'loaded' from slots corresponding
to those local variables.
It is incorrect if phi was stored in a different local variable with a more
specific type and then reloaded.
After this change, type is propagated from local variable to phis only if
phi was created for this local.
Fixes https://github.com/dart-lang/sdk/issues/32597
Change-Id: I7d86c2ef79d14895c9b4c3651d0234b3f9c66173
Reviewed-on: https://dart-review.googlesource.com/47200
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
