const maps with type entries doesn't work properly

[sigmundch]

It took me a while to figure out a bug related to this. Dart2js currently allows const maps with types as keys, but lookup functions fail.

Here is a simple example that reproduces the problem:

    class A {}
    var m1 = { A: 1};
    const m2 = const {A: 2};
    
    main() {
      var t = new A().runtimeType;
      print('${m1[A]} ${m2[A]} ${m1[t]} ${m2[t]}');
      print(m2.keys.first == t)
    }
    

This program works in the vm, there it prints:
   1 2 1 2
   true

in dart2js it prints:
   1 2 1 null
   true

[floitschG]

https://codereview.chromium.org/177053004

---

Set owner to @floitschG.
Added Started label.

[floitschG]

Looks like we are going to disallow Types in const maps.

https://codereview.chromium.org/179293005/

There might be a discussion if we have to special case Types.

[sigmundch]

That's odd - aren't Types consider const symbols too?

[floitschG]

They are. But that doesn't mean that they cannot override their == operator (or hashCode).

It's the same reason they cannot be used in case-clauses.

[floitschG]

When I said "disallow in const maps", I meant as keys. They are still fine as values.

[sigmundch]

I see, thanks for the clarification, makes sense.

I'm obviously not familiar with the implementation details, but I guess I am surprised that Type needs to override ==/hashcode.

[floitschG]

It became necessary to construct types for generic functions. Imagine:

class A<T> {
  foo() => new A<A<T>>();
}

main() { new A<int>.foo().foo().foo()... }

As you can see the set of runtime-types is not known at compile-time. This means that we have to construct them dynamically when needed. Instead of canonicalizing them at runtime, dart2js overrides the equality operator to ensure that they are equal.

[rakudrama]

Regarding #­7 - could we canonicalize the types?
Canonicalized types would allow caching of expensive type tests.
Most real programs run with a bounded number of types.

[karlklose]

Note that we talk about instances of Type here and not about the runtime types that are used in type checks, so this is only about comparing these instances for equality, as there are no subtype tests on Type

Do we have evidence that this is a performance bottleneck anywhere?

[floitschG]

Closing as invalid.
The original example is now a compile-time error, because the Type class overrides "==".

I created a new issue #17207, to track if we can make the behavior the same on the VM and dart2js.

---

Added Invalid label.