SDK fixes

SDK fixes

This fixes all of the static errors from generating the SDK except those in the _interceptors library, and a set of errors associated with checks of the form (v is E) for generic type parameter E.  Most of the fixes consist of adding missing generic parameters, or making overrides consistent.  There are a few fixes to resolve issues around code that moved implicitly between hidden implementation classes and their public API classes, and some other miscellaneous fixes.

All of my changes are in the tool/input_sdk directory - the rest of the diff is generated code.

BUG=
R=vsm@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/e2cc5c78b56f18a4f12d1cebc9963ae8d4c06c70

[Leaf, 2015-05-04 20:50:20]

leafp@google.com changed reviewers:
+ jacobr@google.com, vsm@google.com

[vsm, 2015-05-04 21:09:21]

lgtm

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/core...
File tool/input_sdk/lib/core/list.dart (left):

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/core...
tool/input_sdk/lib/core/list.dart:356: // XXX checkMutable('sort');
Is this cleaning up a previous hack of ours?

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/inte...
File tool/input_sdk/lib/internal/list.dart (right):

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/inte...
tool/input_sdk/lib/internal/list.dart:251: E operator[] (Object key) =>
containsKey(key) ? _values[key] : null;
This is consistent with the Map.[] - but perhaps the cleaner solution is to
change that to take the Key type?  I guess this choice (Object vs the key or val
type) appears a few places though.

[Leaf, 2015-05-04 21:50:42]

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/core...
File tool/input_sdk/lib/core/list.dart (left):

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/core...
tool/input_sdk/lib/core/list.dart:356: // XXX checkMutable('sort');
On 2015/05/04 21:09:21, vsm wrote:
> Is this cleaning up a previous hack of ours?

I asked jacobr about this - the commented out checkMutable was a temporary hack,
no longer needed.  Not sure why there were two versions of sort in the code -
probably a bad merge or an edit fail.

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/inte...
File tool/input_sdk/lib/internal/list.dart (right):

https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/inte...
tool/input_sdk/lib/internal/list.dart:251: E operator[] (Object key) =>
containsKey(key) ? _values[key] : null;
On 2015/05/04 21:09:21, vsm wrote:
> This is consistent with the Map.[] - but perhaps the cleaner solution is to
> change that to take the Key type?  I guess this choice (Object vs the key or
val
> type) appears a few places though.

Yes, I'd probably prefer that as well.  I was trying to minimize breaking API
changes though, with an eye towards potentially upstreaming some of these
changes.

A related one that came up as well was with inconsistent types for Set
intersection and difference (Set<K> vs Set<Object>).

[vsm, 2015-05-05 14:21:42]

On 2015/05/04 21:50:42, leafp wrote:
>
https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/core...
> File tool/input_sdk/lib/core/list.dart (left):
> 
>
https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/core...
> tool/input_sdk/lib/core/list.dart:356: // XXX checkMutable('sort');
> On 2015/05/04 21:09:21, vsm wrote:
> > Is this cleaning up a previous hack of ours?
> 
> I asked jacobr about this - the commented out checkMutable was a temporary
hack,
> no longer needed.  Not sure why there were two versions of sort in the code -
> probably a bad merge or an edit fail.
> 
>
https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/inte...
> File tool/input_sdk/lib/internal/list.dart (right):
> 
>
https://codereview.chromium.org/1112403004/diff/20001/tool/input_sdk/lib/inte...
> tool/input_sdk/lib/internal/list.dart:251: E operator[] (Object key) =>
> containsKey(key) ? _values[key] : null;
> On 2015/05/04 21:09:21, vsm wrote:
> > This is consistent with the Map.[] - but perhaps the cleaner solution is to
> > change that to take the Key type?  I guess this choice (Object vs the key or
> val
> > type) appears a few places though.
> 
> Yes, I'd probably prefer that as well.  I was trying to minimize breaking API
> changes though, with an eye towards potentially upstreaming some of these
> changes.

Sounds good.  Still LGTM.

> 
> A related one that came up as well was with inconsistent types for Set
> intersection and difference (Set<K> vs Set<Object>).

[Leaf, 2015-05-05 17:58:38]

Committed patchset #2 (id:20001) manually as
e2cc5c78b56f18a4f12d1cebc9963ae8d4c06c70 (presubmit successful).