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 .
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 .
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 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 .
Paul Berry