Allow Symbols in switch and maps

Allow Symbols in switch and maps

Allow Symbol literals (and const Symbol instances) as switch expression
and as key values in const Maps.

This implements the most recent Spec changes.

R=regis@google.com

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

[hausner, 2014-12-09 16:51:30]

hausner@google.com changed reviewers:
+ regis@google.com

[regis, 2014-12-09 21:58:56]

LGTM with one question.

https://codereview.chromium.org/781203005/diff/20001/runtime/vm/object_store.cc
File runtime/vm/object_store.cc (right):

https://codereview.chromium.org/781203005/diff/20001/runtime/vm/object_store....
runtime/vm/object_store.cc:193: set_symbol_class(cls);
There are many other "known objects" that are looked up and stored in the object
store, e.g. class ClassID. Is class Symbol special?

Doing it here is fine with me, but why not handle all such objects in the same
location?

[hausner, 2014-12-10 00:23:27]

Thank you

https://codereview.chromium.org/781203005/diff/20001/runtime/vm/object_store.cc
File runtime/vm/object_store.cc (right):

https://codereview.chromium.org/781203005/diff/20001/runtime/vm/object_store....
runtime/vm/object_store.cc:193: set_symbol_class(cls);
On 2014/12/09 21:58:55, regis wrote:
> There are many other "known objects" that are looked up and stored in the
object
> store, e.g. class ClassID. Is class Symbol special?
> 
> Doing it here is fine with me, but why not handle all such objects in the same
> location?

The only reason I'm aware of to do it here is that the objects initialized here
are not allocated programmatically by the VM, since they don't have a
corresponding C++ class. I introduced this for objects from the async library,
but now there's also class Symbol from the internal core library.

We could change this code so the objects are allocated on demand only when the
VM accesses them. I would do this as a separate change.

[hausner, 2014-12-10 00:24:13]

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

[regis, 2014-12-10 00:29:44]

On 2014/12/10 00:23:27, hausner wrote:
> Thank you
> 
>
https://codereview.chromium.org/781203005/diff/20001/runtime/vm/object_store.cc
> File runtime/vm/object_store.cc (right):
> 
>
https://codereview.chromium.org/781203005/diff/20001/runtime/vm/object_store....
> runtime/vm/object_store.cc:193: set_symbol_class(cls);
> On 2014/12/09 21:58:55, regis wrote:
> > There are many other "known objects" that are looked up and stored in the
> object
> > store, e.g. class ClassID. Is class Symbol special?
> > 
> > Doing it here is fine with me, but why not handle all such objects in the
same
> > location?
> 
> The only reason I'm aware of to do it here is that the objects initialized
here
> are not allocated programmatically by the VM, since they don't have a
> corresponding C++ class. I introduced this for objects from the async library,
> but now there's also class Symbol from the internal core library.
> 
> We could change this code so the objects are allocated on demand only when the
> VM accesses them. I would do this as a separate change.

Yes, I think class ClassID is another example without any C++ class. That's why
I asked. Not a big deal.