This script lets you dump as text a partial .dill file generated by the
incremental generator. To do so, it requires that you pass in other .dill files
that are needed (in order).
In the context of a hot-reload test, you should be able to run this as follows:
pkg/front_end/tool/fasta dump-ir newProgram.dill fullProgram.dill platform.dill
BUG=
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2985113002 .
Currently, fasta synthetically closes open braces until it finds
a match for the current closing brace. This works most of the time,
but provides less than optimal recovery in some common cases.
For example, given the following
class { foo()){print(a);} var a = 'hello'; }
the current brace recovery method fails to find any match for the
second closing parenthesis and synthetically closes the class
causing the rest of the file to be parsed as outside the class.
With this CL, fasta still synthetically closes open braces when it finds
a match for the current closing brace, but if there is no match, then
it just skips over the extra closer and continues. This approach dramatically
improves recovery in many cases where there is an extra closing parenthesis
or extra closing square bracket. In the example above, fasta parses
everything after the second closing parenthesis inside the class.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2981343002 .
This is tricky because there isn't a clean correspondence between
analyzer's AST (which reflects user syntax) and kernel representation.
For example:
f(args);
could be a call to a static function f, a method f in the current
class, or an invocation of a function-typed object stored in a
variable called f. ResolutionStorer operates on the kernel
representation, so it sees the difference, but ResolutionApplier
operates on the analyzer AST, so it does not. So we go to some extra
work to make sure a type is stored for f, regardless of whether f is a
function, method, or a variable. This requires some re-ordering logic
in ResolutionStorer, since the inferred type of f is not known until
after the args have been visited.
The implementation is not complete; currently the type that we store
in the first two cases is `dynamic` because the type inference
mechanism doesn't preserve enough information to allow us to determine
the correct type; this will be remidied in a future CL.
A similar situation occurs for:
x.m(args);
which could be a call to a method m in the object x, or an invocation
of a function-typed object returned by the getter m in the object x.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2984013002 .
The type inference engine doesn't even see parenthesized expressions
as a separate entity, since parentheses don't have any semantics. So
we just copy the static type from the enclosed expression.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2982323003 .
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 .
