It is informative in the same way as documentation.
Yesterday I tried to make Analyzer and Analysis Server stop using
FieldFormalParameterElement(s) and found one important use case requested
by the Flutter team. We need to show documentation of a field when
user requests documentation on the corresponding field formal named
parameter. This happens outside of the file that declares the parameter
and the field, so we don't have AST available. Of course we could
resolve the unit, but it would cost us something. And if we decide
that it is OK, then maybe we don't need to have documenation comments
in elements at all.
This is of course more convenience, and we could store documentation
and parameter to field mappings outside, like we store index. Just a
compromise - convenience vs. purity.
R=ahe@google.com, kmillikin@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2983173002 .
This CL propagates types from top level variable declarations into
analyzer ASTs.
This required adding a finishFields method to parser listeners (and a
corresponding method DietListener.listenerFinishFields which calls
it); this allows AnalyzerDietListener to thread the types through from
the BodyBuilder to the AstBuilder. This is similar to what we were
already doing for methods.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2987503003 .
This technically steals a few tests from the previous batch that spans
corelib and language, but I wanted to start from the top of the language
tests.
Removed application_test and application_negative_test because they are
useless and the latter has never actually worked correctly since the day
it was transliterated from the long-defunct application file syntax.
R=bkonyi@google.com, whesse@google.com
Review-Url: https://codereview.chromium.org/2984443003 .
My CL broke dartk/vm tests because I stopped reporting some errors accidentaly.
I thought I was duplicating all error messages, but turns out that recoverable
errors were only reported in the line fixed here.
This reverts to the old behavior so we can address the reporting issues
separately. Added details to: https://github.com/dart-lang/sdk/issues/30194
BUG=
Review-Url: https://codereview.chromium.org/2977423002 .
Changes in this CL:
- Updated CompilerContext:
- it now contains a ProcessedOptions object
- it no longer depends on CompilerCommandLine/CommandLine
- it delegates to ProcessedOptions.report so all error reporting
goes to one single place.
- use "withContext" term instead of "withGlobalOptions" to be
more clear about the intent
- Changes in public API
- added more options that correspond to flags in command-line
fasta tools
- default onError is different: we now use the
command_line_reporting report, which prints and throws
on fatal messages, but doesn't throw eagerly on all messages
as before.
- introduced "printMessages" option: make it easy to have
both onError + command_line_reporting (kernel-service.dart
is the main use case at this time, other ideas welcome!)
- renamed CompilationError to CompilationMessage
- Other changes
- set exit code is done on report, not on format
- fixed corner cases not covered in previous CL
- error reporting with missing-main needs to happen with
a context
- missing error cases when inferring .packages and input
URIs are not file:* URIs
Ideas for follow up after this CL:
- combine ProcessedOptions and CompilerContext into a single class
(or extend one from the other)
- switch onError to a stream
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2982093003 .
Proper sequencing of _asyncStackTraceHelper in Kernel
This helper function was being called before its argument was
initialized so it was passing null. Instead, it should be called
after its argument is initialized.
Because the initialization happens in Kernel code, it is simplest to
insert the call explicitly in Kernel code as well as part of the async
transformation. This has the consequence that we now call the helper
function even when the flag causal_async_stacks is false.
Fixes issue #29771.
Fixes issue #30178
Fixes issue #30058
BUG=
R=aam@google.com, asiva@google.com
Review-Url: https://codereview.chromium.org/2936793003 .
Review-Url: https://codereview.chromium.org/2982943002 .
Note the suite seemed to have a lot of tests crashing in verification.
With my change I'm noting other crashes, but I haven't investigated where they are from.
Also, to run the suite, before it used to be run as:
dart pkg/kernel/test/reify/suite.dart
Now it needs to be run as:
DART_CONFIGURATION=ReleaseX64 out/ReleaseX64/dart pkg/kernel/test/reify/suite.dart
BUG=
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2981813002 .
* make _end(optional: false) which uncovered unbalanced begin/end pairs
* update and document top level member events
* rename handleSwitchCase to endSwitchCase to better align with beginSwitchCase
* update and document begin/endFor/endForIn events
* cleanup test listener
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2980043003 .
This CL propagates types for simple variable declarations into analyzer ASTs.
Note that for a variable declaration like `int x` we need to store two
pieces of information: the element pointed to by `int`, and the type
of `x`. This CL handles the latter. The former will wait until we
have enough of the element model built that we have an element to
point to.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980053002 .
This code is no longer needed because we no longer run the front end
in "kompile" mode.
Also remove the old expectations files used by the "kompile" tests.
I will remove more code in future CLs.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980883003 .
This mode was needed in the early days of the front end when we were
contemplating the idea of building the analyzer AST representation of
code first, and then converting it to kernel. Now that we build
kernel directly, it is no longer needed.
Further CLs will follow to remove code that is no longer used after
this change.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980013002 .
This CL lays the groundwork for integrating the front end with
analyzer by creating a mechanism to copy resolution and type inference
information (produced by the front end's type inference engine) into
analyzer ASTs (produced by AstBuilder).
The general technique is to parse each function twice: once with
BodyBuilder as a listener and once with AstBuilder as a listener. The
BodyBuilder generates a kernel representation of the function, but
this isn't used; instead, type inference and resolution information is
captured using ResolutionStorer (which is a TypeInferenceListener).
Later, this information is applied to the analyzer AST generated by
AstBuilder using ResolutionApplier (which is an analyzer AST visitor).
At the moment the intermediate data exchanged between ResolutionStorer
and ResolutionApplier is simply a list of types (one for each
subexpression, in a post-order traversal of the program syntax). For
debugging and validation purposes, this is augmented with a list of
file offsets, so that if the ResolutionStorer and ResolutionApplier
get out of sync we can diagnose the problem easily.
In later CLs, more data will need to be exchanged between
ResolutionStorer and ResolutionApplier (e.g. a list of elements to
which identifiers are resolved).
This CL doesn't tackle the problem of translating between the kernel
and analyzer representation of types; for now we simply map each type
to `dynamic`. This is sufficient for early development, since it is
still enough to let us verify that ResolutionStorer and
ResolutionApplier stay in sync.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2981693002 .
In a future CL I'm going to start taking advantage of the fact that
these methods provide a fallback behavior when the listener doesn't
override a more specific method, so to avoid confusion I'm renaming
the methods to reflect that use case.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2981653002 .
The test is currently skipped because of some flaky issue (issue #29819). I
noticed the test got broken while it's been disabled. This makes the test be in
working condition, even though it can't be enabled until we fix the underlying
flakiness in the VM.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2976553002 .
Original CL had a bug that wasn't visible unless you delete your
out/ReleaseX64/patched_sdk folder.
Patchset #1 is the original CL, patchset #2 shows the fix.
This reverts commit 4aadfe09df.
BUG=
Review-Url: https://codereview.chromium.org/2976543002 .
This CL tweaks the public APIs in package:front_end, and
starts using those APIs outside the package. For example, this
removes 9 uses of DillTarget, so it is not longer mentioned
outside pkg/front_end and the analyzer_target.
Actual changes:
- in package:front_end
* added kernel_generator_impl: new file contains code that
used to be in kernel_generator. Code has some modifications:
it uses a single canonical-root when loading summaries, and
it supports generating both outlines and kernel in one go.
* removed code that didn't belong here:
a. most of calculating deps for .GN moved to patch_sdk
b. vm-specific outcomes moved to kernel-service
* updated how `native` is implemented, so we can more easily
support dart2js and ddc
* updated how we check where `int`, `bool`, etc can be implemented.
* added support "hermetic mode" in modular builds
('chaseDependencies = false' option)
* moved `trim` step out of fasta, and for now call it only within
the public API. This is not yet exposed, and I stopped covering it in
most tests (now only covered in shaker tests). The plan is to add
tests for the public API covering this in the future.
* removed `uriToSource` when serializing outlines
* added unit tests for public APIs
- patch_sdk
* use the public API to craete platform.dill, outline.dill (now
500K insted of 3Mb because it excludes sources), and vmservice_io.dill
* moved here logic internal to .GN
- kernel service
* use the public API
* moved here logic that depends on VM internals (e.g. status enum,
compilation results)
- package:compiler
* use the public API in tools and unit tests
* simplified patched-sdk generation: no more extending fasta's internals
- package:kernel
* fix bug in deserialization: initializers and other lists were
overwritten accidentally with external definitions.
* updated unit tests, moved shared logic to frontend/src/fasta/testing
R=johnniwinther@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2953703002 .
This CL creates synthetic kernel objects for two additional
BodyBuilder corner cases:
- The synthetic "throw" expression created when code attempts to
construct an abstract class.
- The "throw" expression created when code attempts to assign to a
read-only expression.
With this change, we now create a KernelComplexAssignment object for
all assignments; this has allowed me to streamline the code for
creating assignments slightly.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2972873002 .
* update test because fasta scanner correctly warns on 1.e+2
* fasta scanner correctly produces compile time error
see dartbug.com/28664
fix dartbug.com/28680
* update fasta AsciiControlCharacter error code
* enable fasta scanner in analyzer by default
R=ahe@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2967363003 .
Inline instance object hash code into object header on 64 bit.
64 bit objects have 32 bits of free space in the header word.
This is used for the hash code in string objects. We take it
for the default hash code on all objects that don't override
the hashCode getter.
This is both faster and a memory reduction. Eg it makes the
MegaHashCode part of the Megamorphic benchmark 6 times faster.
This is a reland of https://codereview.chromium.org/2954453002/
which fixes an issue that made script snapshots generated on
64 bit platforms incompatible with 32 bit VMs.
BUG=
R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2965723002 .
We introduce a class KernelSyntheticExpression which can be used for
synthetic expressions introduced by the front end. It is used for
expressions that represent errors detected by the front end, and it is
also the base class for KernelComplexAssignment. By default, type
inference skips these synthetic expressions, inferring a type of
`dynamic`. (Note, however, that classes dervied from
KernelComplexAssignment override this behavior).
We also introduce a class KernelSyntheticStatement which behaves
similarly, but is used for statements rather than expressions,
e.g. the synthetic assignment introduced at the top of a "for" loop
whose loop variable is defined elsewhere.
Finally, we modify KernelTypeInferrer.inferFieldTopLevel() so that it
deliberatly infers `dynamic` for fields that lack an initializer.
Previously this behavior happened as a result of the hack in
KernelTypeInferrer.inferExpression which caused type inference to
infer `dynamic` for anything that didn't implement KernelExpression.
All of these changes should help pave the way for removing the
aforementioned hack.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2968563002 .
This is intended for profiling, to ensure that type inference and type
promotion do not slow down compilation too much.
Currently the option is just plumbed through to the kernel Target
class since I'm not exactly sure how we'll want to enable/disable this
option; we can plumb it the rest of the way in a future CL.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2962913002 .
