This will make it easier to re-link summaries when a file changes,
since all the information that is needed from imported libraries will
be in the "public namespace" section of the summary.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1543403002 .
This way we solve a chicken-and-egg problem with TypeProvider.
Fix for referencing elements from non-first part.
Fix for TODO to update implicit fields for a getter/setter pair.
The type List has it, so I have to fix it to use for SDK summaries.
Add SummaryTypeProvider to use with SDK summaries.
It is initialized in two steps: first dart:core, then dart:async libraries.
resynthesizer = new SummaryResynthesizer(context, typeProvider,
_getPrelinkedSummary, _getUnlinkedSummary, context.sourceFactory);
_buildCoreLibrary();
_buildAsyncLibrary();
void _buildCoreLibrary() {
LibraryElement library = resynthesizer.getLibraryElement('dart:core');
typeProvider.initializeCore(library);
}
void _buildAsyncLibrary() {
LibraryElement library = resynthesizer.getLibraryElement('dart:async');
typeProvider.initializeAsync(library);
}
R=paulberry@google.com, brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1543313002 .
Look at the following code.
main([p = double.INFINITY]) {}
In ConstantVerifier we validate the value of "p" and while doing this validate
the value of the ConstFieldElementImpl that corresponds to "double.INFINITY".
The problem is that we compute "double.INFINITY" in the task that requires
RESOLVED_UNIT_n, where "n" is too high. What we really need is just one value,
not all values, and of course not the resolved unit. And when we will use
summaries, we will be able to provide these values without using AST at all.
So, we need to explicitly require computation of the default value of "p",
an explicit dependency on "double.INFINITY" and its explicit computation.
Currently it still causes using ASTs, but we will change this soon.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1531233002 .
This CL makes the following changes to the mock SDK used by
AnalysisContextFactory.initContextWithCore:
- Getters created by the ElementFactory have their `synthetic`
property set correctly, and their corresponding synthetic fields
have their `final` property set correctly.
- The following class elements all have at least one constructor:
Function, Iterable, Iterator, Map, Null, StackTrace, Type, num,
double, _Proxy.
This allows resynthesize_test.dart's `test_core` to pass.
Also, some minor improvements are made to resynthesize_test.dart to
allow failures to be diagnosed more easily.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1532763002 .
This is necessary in order to properly summarize the core type `Object`,
which lacks a supertype.
Note that there is no test for this functionality in
resynthesize_test.dart. It will be covered as soon as the test
`fail_core` is enabled.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1531913002 .
I notied during reading idl.dart that I'd like to see highlighting and
search for type names in comment references like [PrelinkedLibrary.dependencies].
With this change we get highlighting, search and refactoring for both.
Navigation also works (*).
(*) does not work in IntelliJ - it does not parse Dart comments for reference expressions.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1531613002 .
This makes the UnlinkedLibrary type go away, which means that we no
longer have any unlinked summary data which is spread across the
compilation units constituting a library. That in turn means that we
should be able to safely re-link summaries even in the (pathological)
case where a change to URI resolution affects the relationship between a
library and its parts.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1528113002 .
In addition to simplifying some serialization/deserialization code, this
paves the way for merging the references table with the prefixes table
by allowing the zeroth entry in both tables to act as a sentinel value.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1528083002 .
This is a follow up to commit
f85684604b, which reorganized the
declarations by compilation unit to pave the way for allowing
summaries to be "re-linked" if the relationship between part files
changes. Organizing references by compilation unit is another
necessary step to make that possible.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1523093003 .
In the initial implementation of summaries, all declarations for a
given library were thrown together into a single bucket, regardless of
the compilation unit in which they appeared. This was done on the
grounds that semantically, the compilation unit in which a declaration
appears is irrelevant.
However, it turns out that this conflicts with one of the design goals
of summaries, which is to allow summaries to be quickly "re-linked"
when URI resolution changes. Since "part" declarations use URIs to
refer to part files, this means that URI resolution may affect the
relationship among compilation units within a library; thus, the
declarations for each compilation unit need to be in their own data
structure.
A side benefit of this reorganization is to make the structure of the
summary more similar to the structure of the element model; this
should in turn make it simpler (and possibly more performant) to
convert between element models and summaries.
This CL reorganizes the declarations themselves; future CLs will
reorganize the dependency and resolution information to match.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1530503002 .
Most of this code is already in StrongTypeSystemImpl. A few helpers move there, with some moving into CodeChecker. This does not rename "rules" parameters/variables yet, but let me know if we should do that.
This just moves code around. One subtle thing: TypeRules.isAssignableTo was only used in one place, in override checking, and that method just forwarded to TypeRules.isSubTypeOf. By contrast, StrongTypeSystemImpl does *not* just forward. So OverrideChecker now uses isSubtypeOf, preserving its old behavior.
R=leafp@google.com
Review URL: https://codereview.chromium.org/1507933002 .
Paul Berry