Provisionally stop working around issues 9252 and 9253.

Provisionally stop working around issues 9252 and 9253.

We're removing these workarounds in the hopes that the pub tests won't resume
flaking. If they do, this CL should be rolled back.

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

[Bob Nystrom, 2013-03-20 16:33:42]

Couple of nits then LGTM.

https://codereview.chromium.org/12879015/diff/1/utils/pub/entrypoint.dart
File utils/pub/entrypoint.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/entrypoint.dart#new...
utils/pub/entrypoint.dart:134: return new Future.of(() {
For consistency's sake, how about using defer() here?

https://codereview.chromium.org/12879015/diff/1/utils/pub/io.dart
File utils/pub/io.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/io.dart#newcode586
utils/pub/io.dart:586: return new Future.of(() => fn(tempDir))
What's this change for? Is it just to handle fn() not returning a future? If so,
document that in the doc comment.

https://codereview.chromium.org/12879015/diff/1/utils/pub/system_cache.dart
File utils/pub/system_cache.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/system_cache.dart#n...
utils/pub/system_cache.dart:111: /// Delete's the system cache's internal temp
directory.
"Delete's" -> "Deletes"

[nweiz, 2013-03-20 19:45:46]

https://codereview.chromium.org/12879015/diff/1/utils/pub/entrypoint.dart
File utils/pub/entrypoint.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/entrypoint.dart#new...
utils/pub/entrypoint.dart:134: return new Future.of(() {
On 2013/03/20 16:33:42, Bob Nystrom wrote:
> For consistency's sake, how about using defer() here?

Done, although I think we should remove defer() at some point in favor of
Future.of (or Future.immediate if asynchrony is important).

https://codereview.chromium.org/12879015/diff/1/utils/pub/io.dart
File utils/pub/io.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/io.dart#newcode586
utils/pub/io.dart:586: return new Future.of(() => fn(tempDir))
On 2013/03/20 16:33:42, Bob Nystrom wrote:
> What's this change for? Is it just to handle fn() not returning a future? If
so,
> document that in the doc comment.

Yes; I think we should have the general heuristic that callbacks that are typed
to return a Future can also return null. I'd like to allow them to return
anything the [Future.then] callback can return, but that makes typing them
awkward.

https://codereview.chromium.org/12879015/diff/1/utils/pub/system_cache.dart
File utils/pub/system_cache.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/system_cache.dart#n...
utils/pub/system_cache.dart:111: /// Delete's the system cache's internal temp
directory.
On 2013/03/20 16:33:42, Bob Nystrom wrote:
> "Delete's" -> "Deletes"

*shudder*

[nweiz, 2013-03-20 19:49:17]

Committed patchset #3 manually as r20286 (presubmit successful).

[Bob Nystrom, 2013-03-20 19:49:34]

https://codereview.chromium.org/12879015/diff/1/utils/pub/entrypoint.dart
File utils/pub/entrypoint.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/entrypoint.dart#new...
utils/pub/entrypoint.dart:134: return new Future.of(() {
On 2013/03/20 19:45:46, nweiz wrote:
> On 2013/03/20 16:33:42, Bob Nystrom wrote:
> > For consistency's sake, how about using defer() here?
> 
> Done, although I think we should remove defer() at some point in favor of
> Future.of (or Future.immediate if asynchrony is important).

I'm fine with that (though defer() is a good bit more terse). We added it before
Future.of() existed.

https://codereview.chromium.org/12879015/diff/1/utils/pub/io.dart
File utils/pub/io.dart (right):

https://codereview.chromium.org/12879015/diff/1/utils/pub/io.dart#newcode586
utils/pub/io.dart:586: return new Future.of(() => fn(tempDir))
On 2013/03/20 19:45:46, nweiz wrote:
> On 2013/03/20 16:33:42, Bob Nystrom wrote:
> > What's this change for? Is it just to handle fn() not returning a future? If
> so,
> > document that in the doc comment.
> 
> Yes; I think we should have the general heuristic that callbacks that are
typed
> to return a Future can also return null. I'd like to allow them to return
> anything the [Future.then] callback can return, but that makes typing them
> awkward.

I think the way I tend to approach this is to just have it return a Future and
then wrap the whole body in defer() which will ensure that translation happens.