Change type requirements for {} being a set literal. (#129)

* Change rules for when a set-or-map-literal is a set literal.

The existing rule had some issue. My immediate fix would have different issues. The `FutureOr` case is particularly annoying because `FutureOr<LinkedHashSet<X>>` as a context type should create a `Set<X>`, and `FutureOr<V>` is a super-type of `V` and we don't want to get into zig-zag problems (`Iterable<int>`  is incomarable to `List<num>`, and `Iterable<int>` is incomparable to `FutureOr<List<int>>`).

This change requires answering a negative universal property, but I believe the types in question must be available in the context type, so it should be simple (get the `T` type as the type parameter of `Iterable` if the context type implements iterable, get the `K` and `V` as the type parmeters of `Map` if the context type implements `Map`, and you only need to check those).

* Simplify. Do not attempt to match type variables because they won't work.

Author: lrhn

accepted/future-releases/set-literals/feature-specification.md

@@ -1,5 +1,6 @@
 # Set Literals Design Document
 Author: lrn@google.com
+Version: 1.1
 
 Solution for [Set Literals Problem](http://github.com/dart-lang/language/issues/36).
 Based on feature proposal [Issue 37](http://github.com/dart-lang/language/issues/37)
@@ -84,12 +85,14 @@ if *s* has a `typeArguments` with two type arguments, *s* is a *map literal*.
 (*Three or more type arguments is a compile time error, so the remaining possible case is having no type arguments*).
 
 If *s* is an `emptySetOrMapLiteral` with no `typeArguments` and static context type *C*, then
-if `Set<Null>` is assignable to *C* and `Map<Null, Null>` is not assignable to *C*, then *s* is a *set literal*, 
-otherwise *s* is a *map literal*.
+if `LinkedHashSet<Null>` is assignable to *C* and `LinkedHashMap<Null, Null>` is not assignable to *C*, 
+then *s* is a *set literal*, otherwise *s* is a *map literal*.
 
-(*So if *C* is, for example, `Iterable<int>` or `Set<Object>` or `FutureOr<Iterable<int>>` or a type variable with any of 
-those as bound, then *s* is a set literal. If *C* is `Object` or `dynamic` or `Null` or `String`, then *s* is a map literal, 
-*and* potentially a compile-time error due to static typing*).
+(*So if *C* is, for example, `Iterable<int>`, `Set<Object>`, `LinkedHashSet<int>` or `FutureOr<Iterable<int>>`,
+then *s* is a set literal. If *C* is `Object` or `dynamic` or `Null` or `String`, then *s* is a map literal, 
+*and* potentially a compile-time error due to static typing*. If *C* is some subclass of `Set<X>` other than `LinkedHashSet`, then the literal is a map literal, but it is also a guaranteed type error even if the literal
+is a set. If *C* is a subtype of `LinkedHashSet<X>` *and* a subtype of `LinkedHashMap<Y, Z>`, then *s* is again
+a map literal, and a guaranteed run-time type error).
 
 ### Map literals
 
@@ -357,3 +360,7 @@ var s6                 = {...{1: 1}, ...?d}; // Map<dynamic, dynamic>
 // var s7              = {...?d};            // Compile-time error, ambiguous
 // var s8              = {...{1}, ...{1: 1}};  // Compile-time error, incompatible
 ```
+
+##Revisions
+1.0: Initial version plus type fixes.
+1.1: Changed type rules for selecting set literals over map literals.