Fix failure using custom drivers with AnalysisDriverScheduler

Fix failure using custom drivers with AnalysisDriverScheduler

Or alternatively, the AnalysisDriverGeneric interface could be extended?

BUG=
R=brianwilkerson@google.com

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

[mfairhurst, 2017-04-14 00:22:04]

mfairhurst@google.com changed reviewers:
+ brianwilkerson@google.com

[Brian Wilkerson, 2017-04-17 16:07:15]

I'm not sure I understand the need for this check, but I suspect it is the
result of some kind of version-based confusion. The getter contextRoot was added
to AnalysisDriverGeneric, which means that you'll need to add support in your
subclass in order to not have compilation errors. Are we compiling and building
the angular support against two different versions of the SDK?

[mfairhurst, 2017-04-17 16:13:28]

On 2017/04/17 16:07:15, Brian Wilkerson wrote:
> I'm not sure I understand the need for this check, but I suspect it is the
> result of some kind of version-based confusion. The getter contextRoot was
added
> to AnalysisDriverGeneric, which means that you'll need to add support in your
> subclass in order to not have compilation errors. Are we compiling and
building
> the angular support against two different versions of the SDK?

I believe the problem here was that it was being downcast to AnalysisDriver,
where later `resourceFactory` was being called on it. I will double check,
because you're right, this does look suspiciously like versioning problems (I
remember it accessing `resourceFactory` on this line of code, not sure if I was
seeing what I expected based on the eventual error, or if I fixed a problem no
longer present in HEAD)

[Brian Wilkerson, 2017-04-17 16:21:51]

> I believe the problem here was that it was being downcast to AnalysisDriver,
> where later `resourceFactory` was being called on it.

That would obviously be a bug, and is where the fix really belongs. If we can
identify where that's happening, let's move the test to there.

[mfairhurst, 2017-04-17 17:03:26]

On 2017/04/17 16:21:51, Brian Wilkerson wrote:
> > I believe the problem here was that it was being downcast to AnalysisDriver,
> > where later `resourceFactory` was being called on it.
> 
> That would obviously be a bug, and is where the fix really belongs. If we can
> identify where that's happening, let's move the test to there.

Right, so this is where the downcast to AnalysisDriver occurs. Alternatively, I
could change the DriverWatcher interface to accept AnalysisDriverGeneric's, and
then it wouldn't be a downcast, and accessing members that aren't on the
interface (like resourceProvider) would be static errors until we extend the
interface, which we can coordinate.

I guess the question then is -- do you want AngularDriver's sent into the
DriverWatcher?

[Brian Wilkerson, 2017-04-17 21:02:34]

> Right, so this is where the downcast to AnalysisDriver occurs.

Ah, I misunderstood. Then this is the right place for the 'is' test, and this CL
lgtm.

> I guess the question then is -- do you want AngularDriver's sent into the
> DriverWatcher?

No. The purpose of the watcher is to figure out when we've seen a reference to a
package that defines a plugin so that we can start running the plugin. An
AngularDriver (long term) will only be created inside the plugin, so there won't
be any way of passing it into the watcher.

[mfairhurst, 2017-04-18 21:03:04]

Description was changed from

==========
Fix failure using custom drivers with AnalysisDriverScheduler

Or alternatively, the AnalysisDriverGeneric interface could be extended?

BUG=
==========

to

==========
Fix failure using custom drivers with AnalysisDriverScheduler

Or alternatively, the AnalysisDriverGeneric interface could be extended?

BUG=
R=brianwilkerson@google.com

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

[mfairhurst, 2017-04-18 21:03:06]

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