* update the fasta scanner to generate comment and dartdoc tokens
* replace fasta.preceedingComments field
with preceedingCommentTokens field and preceedingComments getter/setter
* update token translator
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2763833002 .
These utilities are needed for generating the code that supports
summaries; in order to move summary logic into front_end, we will need
these code generation tools in front_end as well.
Also make a minor change to summary code generation logic so that it
talks to the file system directly rather than depending on analyzer's
file system abstraction.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2742333005 .
The end goal is to move summary logic to the front end, which means
that it won't be able to depend on analyzer. This removes a key
dependency on analyzer (the dependency of the code generator on the
analyzer parser).
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2748803003 .
Previously this was working for a few use cases by dumb luck, but it
wasn't well tested and became broken by
b29c6bf330. This CL fixes it for real
and adds tests to verify the fix.
Note that there is a change to how we represent an unresolved
import/export: instead of storing a URI_EXISTS modifier in the element
model, we simply mark the imported library element as synthetic.
(This library element existed anyway; we just weren't marking it as
synthetic). This makes it easy to tie in with summaries, since it is
easy for the resynthesizer to detect that the library doesn't exist at
the time the library handle is resolved.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2235373003 .
The API signature of a summary is an MD5 hash of the API of the code
being summarized. This will be used by analysis server to detect when
a summary needs to be relinked (because it was built with reference to
another summary whose API has since changed).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2216873003 .
Consider libraries `A`, `B`, and `C`, where `C` imports `B`, and `B`
exports `A`. [RESOLVED_UNIT4] of `C` depends on [LIBRARY_ELEMENT4] of
[IMPORTED_LIBRARIES], i.e. `B`. Even though [LIBRARY_ELEMENT4] of `B`
depends on [LIBRARY_ELEMENT3]s of its [EXPORT_SOURCE_CLOSURE] (i.e. `A`
and `B`), [RESOLVED_UNIT4] of `C` sees only [LIBRARY_ELEMENT4] of `B`.
When invalidate results of `B` (but keep results of `C`), we will
invalidate and remove [LIBRARY_ELEMENT4] of `B`, so we lose knowledge
that [RESOLVED_UNIT4] of `C` indirectly depends on `A`.
The solution is do depend on [EXPORT_SOURCE_CLOSURE] of all
[IMPORTED_LIBRARIES] in [RESOLVED_UNIT4] of `C`.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/2171673002 .
These assertions were helpful back when the client manually managed
offsets. Now that offsets are managed automatically by the toBuffer()
logic, they don't carry any benefit.
Removing these assertions will pave the way for allowing a summary to be
created, serialized, modified, and then serialized again, which we will
need to do to efficiently generate both "full" and "semantic" summaries.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2110693002 .
Options are largely unused but are in line with what is specified in CLI to support `build_mode` bringing us a step closer to a unified summary builder and in the short term to a provisional API that should work for Flutter SDK generation experiments in the next alpha release.
BUG=
R=brianwilkerson@google.com, paulberry@google.com
Review URL: https://codereview.chromium.org/2078033002 .
Steps towards generalizing summary creation bits (to allow for, among other things, flutter SDK summary creation). API is provisional (note still in `lib/src`).
Next up:
* move result writing out of `tool/` to allow for reuse
* `SummaryBuilder.forPackageMap(..)` factory (or similar) for use in the flutter SDK case
BUG=
R=brianwilkerson@google.com, paulberry@google.com
Review URL: https://codereview.chromium.org/2055543002 .
We now disambiguate all types by their full library
URI (e.g. "dart:core.Map" instead of "Map"). In addition, we now expand
function types based on local functions into their arguments and return
types (e.g. "() -> dynamic" rather than
"typeof(....localFunction[0].localFunction[0])".
This allows more accurate comparison of AST-based and element-based
summaries.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1997753002 .
This paves the way for further improvements to dump_inferred_types to
allow it to make use of linker data structures. That will in turn make
it easier to validate the linker code by exercising more of it.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1969313006 .
This makes it easier to compare the output of AST-based and
element-based summaries, since element-based summaries cannot
distinguish between implicit type arguments and explicitly-specified
type arguments that happen to match the default (usually `dynamic`).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1957133002 .
Konstantin Shcheglov