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 .
In rare cases a summary package bundle may contain a LinkedLibrary
object but not its corresponding UnlinkedUnits. (This could happen, for
instance, if both a package and one of its dependencies contain
libraries that reference the same file as a "part"--in this case, the
UnlinkedUnit for the part might only be included in one of the package
bundles, because it is redundant in the other).
This CL modifies dump_inferred_types.dart so that it doesn't crash in
this rare corner case.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1930663003 .
Konstantin Shcheglov