-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Type
values obtained from a typedef should represent the underlying type, not the typedef
#32782
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Type
values obtained from a typedef should represent the underlying type, not the typedef
#32783
Is there a test that will pass once the subtask(s) are complete? |
Yes,
Again, I hope that this can be fixed in the common front end and then the other tasks will just evaporate, but I couldn't know for sure so I created subtasks for the tools where I could see the issue. |
Note that the entire topic of |
typedef F1 = void Function(int);
typedef F2 = void Function(int);
typedef void F3(int);
typedef G1 = X Function<X>(X);
typedef G2 = X Function<X>(X);
typedef G3 = Y Function<Y>(Y);
main() {
Expect.equals(F1, F2); //# 01: ok
Expect.equals(F1, F3); //# 02: ok
Expect.equals(G1, G2); //# 03: ok
Expect.equals(G1, G3); //# 04: ok
} I can't see how |
No, the test is buggy and I hadn't seen that (when I wrote it I forgot that |
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]>
The work on tests concerned with instantiate-to-bound and super-bounded types has a dynamic aspect, and for those tests it is important that we can compare @kmillikin, I can see that the subtask for fasta, the vm, and dart2js are still open, and I suspect that they will get this from the common front end (that is, simultaneously, when the front end has it). Do you agree, or is there a backend part as well? Also, is this issue in the pipeline, or could it take a while before it is expected to happen? |
[Edit eernstg as indicated here: adding omitted
x
toF3
.]Cf. this and this comment, certain equalities should hold for objects of type
Type
. In particular, consider the following test:The specified equalities are expected because the given
Type
values should be compared based on the underlying type (such asvoid Function(int)
) rather than the type alias as such (such asF1
). This is in line with the fact that type aliases are aliases for existing types, rather than nominally distinct types:However, current Dart tools do not implement this comparison as expected above. This issue is concerned with adjusting the tools such that the test succeeds. It is allowed (and probably useful) for
Type.toString()
, stack traces, error messages, etc. to refer to the names of type aliases rather than (or in addition to) the underlying function type, this issue is only about the semantics ofType.operator ==
.Subtasks
Note that it is possible that the vm, dart2js, and dartdevc will automatically have this issue resolved when the common front end resolves it.
Type
values obtained from a typedef should represent the underlying type, not the typedef #31359.Type
values obtained from a typedef should represent the underlying type, not the typedef #32783.Type
values obtained from a typedef should represent the underlying type, not the typedef #32784.Type
values obtained from a typedef should represent the underlying type, not the typedef #32785.The text was updated successfully, but these errors were encountered: