Element no longer implements AnalysisTarget

Element no longer implements AnalysisTarget

It looks like all Elements that are used as an AnalysisTarget
(and so can be used as a cache map key) are within the
ConstantEvaluationTarget type hierarchy.

BUG=

[skybrian, 2016-01-31 08:10:58]

skybrian@google.com changed reviewers:
+ brianwilkerson@google.com, scheglov@google.com

[skybrian, 2016-01-31 08:10:58]

All tests pass but I'm not certain about this one. Are there any other cases
where an Element is used as an AnalysisTarget?

[Brian Wilkerson, 2016-02-01 15:43:21]

> All tests pass but I'm not certain about this one.

I'm not either.

> Are there any other cases where an Element is used as an AnalysisTarget?

Not that I know of, but we have discussed before the possibility of being able
to resolve the bodies of functions / methods independently of one another, which
would then require keeping some kind of a key in the cache to represent each
function, and the element seems like the natural fit.

On the other hand, we might want to find a solution that doesn't requiring using
elements as keys in the cache at all, which would take care of both use cases.

Let's hold off on this CL until we've had a chance to figure out where we're
going.

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/dart/eleme...
File pkg/analyzer/lib/dart/element/element.dart (right):

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/dart/eleme...
pkg/analyzer/lib/dart/element/element.dart:662: Source get source;
This needs to have a doc comment, and probably ought to be marked as @deprecated
given that the only reason for it being here was to support the AnalysisTarget
interface.

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/src/contex...
File pkg/analyzer/lib/src/context/cache.dart (right):

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/src/contex...
pkg/analyzer/lib/src/context/cache.dart:933: (target as ElementImpl).frozen =
true;
Seem like this change should be moved back to the CL that adds the field
"frozen" in case we commit one but not the other.

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/src/genera...
File pkg/analyzer/lib/src/generated/incremental_resolver.dart (right):

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/incremental_resolver.dart:2069:
cache.remove(element as AnalysisTarget);
Is the cast necessary? I would have thought that type propagation would be
sufficient.

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/src/task/d...
File pkg/analyzer/lib/src/task/dart.dart (right):

https://codereview.chromium.org/1657463002/diff/1/pkg/analyzer/lib/src/task/d...
pkg/analyzer/lib/src/task/dart.dart:1827: Element elt = target as Element;
This shouldn't be necessary because of type propagation.

[skybrian, 2016-02-01 22:31:10]

On 2016/02/01 15:43:21, Brian Wilkerson wrote:
> > All tests pass but I'm not certain about this one.
> 
> I'm not either.
> 
> > Are there any other cases where an Element is used as an AnalysisTarget?
> 
> Not that I know of, but we have discussed before the possibility of being able
> to resolve the bodies of functions / methods independently of one another,
which
> would then require keeping some kind of a key in the cache to represent each
> function, and the element seems like the natural fit.
> 
> On the other hand, we might want to find a solution that doesn't requiring
using
> elements as keys in the cache at all, which would take care of both use cases.

Okay, I will wait.

I think that, whatever we choose, only the Element subtypes that are actually
used
as AnalysisTargets should implement AnalysisTarget. Otherwise it's more
confusing
to figure out what's going on.