vm: `Type` values obtained from a typedef should represent the underlying type, not the typedef #32783

eernstg · 2018-04-05T13:05:02Z

This is the vm specific issue for #32782, which has the details. Note that it is possible that it will be resolved because the issue is handled by the common front end.

The point is that #32782 requests a fix such that `typedef F1 = void Function(int)` and `typedef void F2(int)` satisfy that `F1 == F2` evaluates to true. This is marked 'p3-low' for the common front end but 'p1-high' for DDC. It seems likely to me that this could create the situation where code is developed using DDC, is working, and then fails upon deployment using the vm. Also, there is a single case where `dart2js` fails in the associated `type_alias_equality_test.dart`, so deployment on the web would also fail upon deployment, though only in some of the cases. However, with some input from Aske I concluded that the situation might have arisen because there _is_ no work to do for this in the common front end, because it will be handled by the backend (which also explains why `dart2js` has it almost right). This CL is just introducing a tiny change: It changes the issue indicated for all VM related failures in said test to point to #32783, which is presumably the right issue for backend work. Apart from that, I've added you, the reviewers, in order to make sure that the relevant people get this heads up. We may then decide to land this CL, change the priority on #31359, do nothing, or whatever turns out to be the right response. ;-) Change-Id: I92672547d7fe795e877604c0da1e0e4579e4e04a Reviewed-on: https://dart-review.googlesource.com/74403 Reviewed-by: Jenny Messerly <[email protected]>

eernstg · 2019-04-26T07:00:48Z

Note that the associated test language_2/type_alias_equality_test.dart still fails on several configurations of the vm as of April 25, 2019.

However, it succeeds with dart2js compiled code, so the expectation that

it is possible that it will be resolved because the issue is handled by the common front end

does not seem to be valid, and vm specific work would then be needed.

eernstg mentioned this issue Apr 5, 2018

Type values obtained from a typedef should represent the underlying type, not the typedef #32782

Open

4 tasks

eernstg added area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Apr 5, 2018

eernstg mentioned this issue Jul 10, 2019

Type equality inconsistency for generic functions. #37484

Open

alexmarkov mentioned this issue Oct 9, 2019

The switch from Bytecode to AST has revealed differences in behavior which were approved #38782

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

vm: `Type` values obtained from a typedef should represent the underlying type, not the typedef #32783

vm: `Type` values obtained from a typedef should represent the underlying type, not the typedef #32783

eernstg commented Apr 5, 2018 •

edited

Loading

eernstg commented Apr 26, 2019 •

edited

Loading

vm: Type values obtained from a typedef should represent the underlying type, not the typedef #32783

vm: Type values obtained from a typedef should represent the underlying type, not the typedef #32783

Comments

eernstg commented Apr 5, 2018 • edited Loading

eernstg commented Apr 26, 2019 • edited Loading

vm: `Type` values obtained from a typedef should represent the underlying type, not the typedef #32783

vm: `Type` values obtained from a typedef should represent the underlying type, not the typedef #32783

eernstg commented Apr 5, 2018 •

edited

Loading

eernstg commented Apr 26, 2019 •

edited

Loading