DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for CONTAINING_LIBRARIES.

DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for CONTAINING_LIBRARIES.

Otherwise, because we don't actually parse units for summarized sources,
we don't build this information in DartWorkManager. But we have it
in summaries.

This fixes the problem when user opens a SDK unit and does not see any semantic highlighting, navigation, etc - because we were not able to create its fully resolved AST (which is library specific, so we need to know containing libraries). Less obvious, but similar problem is that search for references to elements defined in SDK was not working, because IDEA asks search using file and offset _in the SDK_, not at the place in workspace where it is used.

R=brianwilkerson@google.com, paulberry@google.com
BUG=

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

[scheglov, 2016-07-27 17:42:44]

Description was changed from

==========
DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for
CONTAINING_LIBRARIES.

Otherwise, because we don't actually parse units for summarized sources,
we don't build this information in DartWorkManager. But we have it
in summaries.

R=brianwilkerson@google.com, paulberry@google.com
BUG=
==========

to

==========
DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for
CONTAINING_LIBRARIES.

Otherwise, because we don't actually parse units for summarized sources,
we don't build this information in DartWorkManager. But we have it
in summaries.

This fixes the problem when user opens a SDK unit and does not see any semantic
highlighting, navigation, etc - because we were not able to create its fully
resolved AST (which is library specific, so we need to know containing
libraries).

R=brianwilkerson@google.com, paulberry@google.com
BUG=
==========

[scheglov, 2016-07-27 17:44:12]

Description was changed from

==========
DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for
CONTAINING_LIBRARIES.

Otherwise, because we don't actually parse units for summarized sources,
we don't build this information in DartWorkManager. But we have it
in summaries.

This fixes the problem when user opens a SDK unit and does not see any semantic
highlighting, navigation, etc - because we were not able to create its fully
resolved AST (which is library specific, so we need to know containing
libraries).

R=brianwilkerson@google.com, paulberry@google.com
BUG=
==========

to

==========
DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for
CONTAINING_LIBRARIES.

Otherwise, because we don't actually parse units for summarized sources,
we don't build this information in DartWorkManager. But we have it
in summaries.

This fixes the problem when user opens a SDK unit and does not see any semantic
highlighting, navigation, etc - because we were not able to create its fully
resolved AST (which is library specific, so we need to know containing
libraries). Less obvious, but similar problem is that search for references to
elements defined in SDK was not working, because IDEA asks search using file and
offset _in the SDK_, not at the place in workspace where it is used.

R=brianwilkerson@google.com, paulberry@google.com
BUG=
==========

[Paul Berry, 2016-07-27 17:54:21]

On 2016/07/27 17:41:23, scheglov wrote:

What will happen if a part file is used both by a library within a summary and a
library not within a summary, e.g. we are analyzing the following files:

foo.dart: library x; part 'baz.dart';
bar.dart: library x; part 'baz.dart';
baz.dart: part of x;

And we have the following summaries:
- foo.ds: summary file containing summary of foo.dart and baz.dart

It seems like in this case getLibrariesContainingPart(baz.dart) will return
[foo.dart], but it should actually return [foo.dart, bar.dart].

[Brian Wilkerson, 2016-07-27 18:00:07]

lgtm

[scheglov, 2016-07-27 18:09:20]

On 2016/07/27 17:54:21, Paul Berry wrote:
> On 2016/07/27 17:41:23, scheglov wrote:
> 
> What will happen if a part file is used both by a library within a summary and
a
> library not within a summary, e.g. we are analyzing the following files:
> 
> foo.dart: library x; part 'baz.dart';
> bar.dart: library x; part 'baz.dart';
> baz.dart: part of x;
> 
> And we have the following summaries:
> - foo.ds: summary file containing summary of foo.dart and baz.dart
> 
> It seems like in this case getLibrariesContainingPart(baz.dart) will return
> [foo.dart], but it should actually return [foo.dart, bar.dart].

I think you're right, we will return only one of the containing libraries.
But it must be a very rare case when we include sources from SDK or other
libraries as parts.
I will land this CL as is, and return to this case later.

[scheglov, 2016-07-27 18:11:28]

Description was changed from

==========
DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for
CONTAINING_LIBRARIES.

Otherwise, because we don't actually parse units for summarized sources,
we don't build this information in DartWorkManager. But we have it
in summaries.

This fixes the problem when user opens a SDK unit and does not see any semantic
highlighting, navigation, etc - because we were not able to create its fully
resolved AST (which is library specific, so we need to know containing
libraries). Less obvious, but similar problem is that search for references to
elements defined in SDK was not working, because IDEA asks search using file and
offset _in the SDK_, not at the place in workspace where it is used.

R=brianwilkerson@google.com, paulberry@google.com
BUG=
==========

to

==========
DartWorkManager.getLibrariesContainingPart() should ask the ResultProvider for
CONTAINING_LIBRARIES.

Otherwise, because we don't actually parse units for summarized sources,
we don't build this information in DartWorkManager. But we have it
in summaries.

This fixes the problem when user opens a SDK unit and does not see any semantic
highlighting, navigation, etc - because we were not able to create its fully
resolved AST (which is library specific, so we need to know containing
libraries). Less obvious, but similar problem is that search for references to
elements defined in SDK was not working, because IDEA asks search using file and
offset _in the SDK_, not at the place in workspace where it is used.

R=brianwilkerson@google.com, paulberry@google.com
BUG=

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

[scheglov, 2016-07-27 18:11:30]

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