Rewrite DeclarationResolver to match declarations to elements by order rather than offset.

Rewrite DeclarationResolver to match declarations to elements by order rather than offset.

Previously, DeclarationResolver matched declarations to elements using their offsets in the file.  This meant that it could not work with element models built from a summary, since those element models are not guaranteed to contain offsets.  Now, DeclarationResolver assumes that elements appear in the same order in the element model as they do in the file, so it can just match them up using their order.

DeclarationResolver continues to verify element names as it does its matching, so if the ordering of elements ever fails to match up with the ordering of declarations, an exception is almost certain to be thrown.  (The only time it wouldn't be is if the mismatch can't be detected due to multiple elements having the same name).

The new implementation is ~1.6x faster than the previous one.

R=brianwilkerson@google.com, scheglov@google.com

Committed: https://github.com/dart-lang/sdk/commit/524a7da14146a4e2ea0db22ff197d56cb5d06a5c

[Paul Berry, 2016-10-12 19:31:59]

Description was changed from

==========
Rewrite DeclarationResolver to match declarations to elements by order rather
than offset.

Previously, DeclarationResolver matched declarations to elements using their
offsets in the file.  This meant that it could not work with element models
built from a summary, since those element models are not guaranteed to contain
offsets.  Now, DeclarationResolver assumes that elements appear in the same
order in the element model as they do in the file, so it can just match them up
using their order.

DeclarationResolver continues to verify element names as it does its matching,
so if the ordering of elements ever fails to match up with the ordering of
declarations, an exception is almost certain to be thrown.  (The only time it
wouldn't be is if the mismatch can't be detected due to multiple elements having
the same name).
==========

to

==========
Rewrite DeclarationResolver to match declarations to elements by order rather
than offset.

Previously, DeclarationResolver matched declarations to elements using their
offsets in the file.  This meant that it could not work with element models
built from a summary, since those element models are not guaranteed to contain
offsets.  Now, DeclarationResolver assumes that elements appear in the same
order in the element model as they do in the file, so it can just match them up
using their order.

DeclarationResolver continues to verify element names as it does its matching,
so if the ordering of elements ever fails to match up with the ordering of
declarations, an exception is almost certain to be thrown.  (The only time it
wouldn't be is if the mismatch can't be detected due to multiple elements having
the same name).

The new implementation is ~1.6x faster than the previous one.
==========

[Paul Berry, 2016-10-12 19:32:37]

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

[Paul Berry, 2016-10-12 19:32:38]

Note: this CL is not ready to land yet (we would need to first modify the
incremental resolver so that it preserves declaration order).  But I would
appreciate code review comments now.

[scheglov, 2016-10-13 00:45:03]

LGTM

[Brian Wilkerson, 2016-10-13 13:37:04]

lgtm

[scheglov, 2016-10-13 16:00:48]

I looked into IncrementalCompilationUnitElementBuilder implementation, and it
already keeps order or nodes and elements in sync.
I'm adding new tests https://codereview.chromium.org/2413023003 to keep this
behavior.

[Paul Berry, 2016-10-13 16:09:59]

On 2016/10/13 16:00:48, scheglov wrote:
> I looked into IncrementalCompilationUnitElementBuilder implementation, and it
> already keeps order or nodes and elements in sync.
> I'm adding new tests https://codereview.chromium.org/2413023003 to keep this
> behavior.

Awesome!  In that case I'll go ahead and land this.

[Paul Berry, 2016-10-13 19:24:59]

Description was changed from

==========
Rewrite DeclarationResolver to match declarations to elements by order rather
than offset.

Previously, DeclarationResolver matched declarations to elements using their
offsets in the file.  This meant that it could not work with element models
built from a summary, since those element models are not guaranteed to contain
offsets.  Now, DeclarationResolver assumes that elements appear in the same
order in the element model as they do in the file, so it can just match them up
using their order.

DeclarationResolver continues to verify element names as it does its matching,
so if the ordering of elements ever fails to match up with the ordering of
declarations, an exception is almost certain to be thrown.  (The only time it
wouldn't be is if the mismatch can't be detected due to multiple elements having
the same name).

The new implementation is ~1.6x faster than the previous one.
==========

to

==========
Rewrite DeclarationResolver to match declarations to elements by order rather
than offset.

Previously, DeclarationResolver matched declarations to elements using their
offsets in the file.  This meant that it could not work with element models
built from a summary, since those element models are not guaranteed to contain
offsets.  Now, DeclarationResolver assumes that elements appear in the same
order in the element model as they do in the file, so it can just match them up
using their order.

DeclarationResolver continues to verify element names as it does its matching,
so if the ordering of elements ever fails to match up with the ordering of
declarations, an exception is almost certain to be thrown.  (The only time it
wouldn't be is if the mismatch can't be detected due to multiple elements having
the same name).

The new implementation is ~1.6x faster than the previous one.

R=brianwilkerson@google.com, scheglov@google.com

Committed:
https://github.com/dart-lang/sdk/commit/524a7da14146a4e2ea0db22ff197d56cb5d06a5c
==========

[Paul Berry, 2016-10-13 19:25:00]

Committed patchset #1 (id:1) manually as
524a7da14146a4e2ea0db22ff197d56cb5d06a5c (presubmit successful).