Take the parts that I would have simply copied and pasted them into my
own code, and create new public & private methods to serve the new
organization.
Add an option to get the current class's accessors/methods along with
the inherited ones, because that's what I want.
Make opType a public member of DartCompletionRequest
Its used so heavily by so many of the autocomplete targets, it really
doesn't need to be hidden on the Impl.
Besides, I want to use InheritedReferenceContributor, which upcasts the
DartCompletionRequest into the Impl in order to grab this field -- but
for a large number of reasons I can't really use
DartCompletionRequestImpl. Therefore I need my own class to implement
DartCompletionRequest and therefore my code will only work with
InheritedReferenceContributor if it doesn't have to look outside the
interface for this information.
Change to enable the angular analysis project to do autocomplete
We don't have CompilationUnits, but we do have dart ASTs, and we want to
find the completion target with the same algorithm. The CompletionTarget
class's functionality doesn't depend on its member compilationUnit not
being null, so that isn't a problem for us. However, in `forOffset()`,
we cannot pass in a null unit, even though its only used to set the
`compilationUnit` member and otherwise only used as an `AstNode` which
we have.
So rather than using `compilationUnit` as the entry point of the
algorithm, add a new `AstNode` parameter to represent the entry point,
and when its null simply use the value of `compilationUnit`.
BUG=
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2565633002 .
This CL creates top level accessor functions which may be used to map from AST data structures to their corresponding elements and types, and begins using those accessor functions throughout the SDK. It also adds empty interfaces ResolutionTarget and ResolutionType, which are implemented by Element and DartType respectively.
In a future CL, I will change the types stored in the AST to ResolutionTarget and ResolutionType, rather than specific element types; this will decouple the ASTs from the element model. The presence of the accessor functions will allow clients to continue accessing elements and types in a type-safe way.
R=asgerf@google.com, brianwilkerson@google.com, scheglov@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2551023005 .
It turned out to be easier than I thought is would be.
The potential problem was to find correspondence between AnalysisResult
and the AnalysisDriver instance to request top-level declarations in.
But if we just include the AnalysisDriver into AnalysisResult, this
solves the problem.
This creates another problem though - now we need to be careful to
not cache an instance of AnalysisResult for a long time.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2549143007 .
This is the same as 1d028eed8d (which
was reverted) except that it doesn't remove the old AST factory
constructors (which broke dev_compiler). The removal of old AST
factory constructors will be done in a follow-up CL so that if it
unexpectedly breaks any other clients we will be able to revert it
without reverting this CL.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2536373008 .
We are not going to have LibraryElement(s) for the new analysis driver.
The current approach: get known library sources, compute their elements,
import these elements does not work well when there is no analysis cache.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/2532393008 .
Brian Wilkerson