Change imports to fix the build

Change imports to fix the build

R=nweiz@google.com

Committed: https://code.google.com/p/dart/source/detail?r=44405

[Brian Wilkerson, 2015-03-10 20:42:48]

brianwilkerson@google.com changed reviewers:
+ nweiz@google.com, rnystrom@google.com

[Brian Wilkerson, 2015-03-10 20:42:49]

A recent change to the command-line analyzer broke several bots. The change was
to start analyzing files in the 'lib' directory as if they had been found via a
'package:' URI. These two files contain relative imports that effectively
reference code in a different package, meaning that when we resolve the relative
paths against the initial package URI it results in an invalid path.

I can think of two solutions. The first, which I have proposed here, is to
replace the imports in question with 'package:' imports that work. It seems like
the right way to solve the problem, but I might not understand all of the
implications of such a change.

The second would be to special case the handling of code in sdk/lib/_internal,
but I find that to be an ugly hack, and would prefer a cleaner solution.

If you like these changes, then I will ask for instructions for how to run the
pub tests so that I can fully test the solution before committing. If you don't
and have suggestions for a third alternative, I'd love to hear about it.

[nweiz, 2015-03-10 20:47:57]

On 2015/03/10 20:42:49, Brian Wilkerson wrote:
> A recent change to the command-line analyzer broke several bots. The change
was
> to start analyzing files in the 'lib' directory as if they had been found via
a
> 'package:' URI. These two files contain relative imports that effectively
> reference code in a different package, meaning that when we resolve the
relative
> paths against the initial package URI it results in an invalid path.
> 
> I can think of two solutions. The first, which I have proposed here, is to
> replace the imports in question with 'package:' imports that work. It seems
like
> the right way to solve the problem, but I might not understand all of the
> implications of such a change.
> 
> The second would be to special case the handling of code in sdk/lib/_internal,
> but I find that to be an ugly hack, and would prefer a cleaner solution.
> 
> If you like these changes, then I will ask for instructions for how to run the
> pub tests so that I can fully test the solution before committing. If you
don't
> and have suggestions for a third alternative, I'd love to hear about it.

lgtm

These relative imports are left over from before the compiler was package-ified
(to the extent that it is now). I'm pretty sure we're not relying on them being
relative.

You can run pub tests by running "./tools/test.py -m release pub".

[Brian Wilkerson, 2015-03-10 21:23:48]

> You can run pub tests by running "./tools/test.py -m release pub".

Thanks! The tests fail, but then most of the pub bots are red at the moment.
It's hard to know whether this CL actually changes anything.

[Brian Wilkerson, 2015-03-11 16:48:05]

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