return field.value;It doesn't feel like this is testing anything regarding the deletion of the static field since the access after is not through the static field at all. That happened in the first generation when it still existed.
I see that the existing test can't really be copied 1:1 so we have to try to figure out what they are testing.
What does the VM do if we tearoff a function that accesses Foo.x in it's body and then call the tearoff in the generation where the static field has been removed?
"type '(A) => bool' is not a subtype of type '(B) => bool' of 'function "
"result'",Does the TypeError message from DDC match this? If not we might need to get more creative in how we test for the expected error in both DDC and the VM.
"type 'List<B>' is not a subtype of type 'List<A>' of 'function result'",ditto
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
return field.value;It doesn't feel like this is testing anything regarding the deletion of the static field since the access after is not through the static field at all. That happened in the first generation when it still existed.
I see that the existing test can't really be copied 1:1 so we have to try to figure out what they are testing.
What does the VM do if we tearoff a function that accesses Foo.x in it's body and then call the tearoff in the generation where the static field has been removed?
My best guess is that they're checking for "intended" memory leaks (counting allocated heap objects).
With a tearoff, it yields
`
NoSuchMethodError: No static getter 'x' declared in class 'null'.
`
That might be the only DDC-relevant side effect of deleting (then accessing) a static field. I can capture that behavior here and leave the memory checking out. Thoughts?
"type '(A) => bool' is not a subtype of type '(B) => bool' of 'function "
"result'",Does the TypeError message from DDC match this? If not we might need to get more creative in how we test for the expected error in both DDC and the VM.
Good call. We check substring matches, so I'll just remove the portion that we don't emit. Luckily, that's just the 'result' part. If we see something more complex, I'm inclined to unify our errors (or get clever).
"type 'List<B>' is not a subtype of type 'List<A>' of 'function result'",Mark Zhouditto
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
// https://github.com/dart-lang/sdk/blob/63622f03eeaf72983b2f4957fa84da8062693f00/runtime/vm/isolate_reload_test.cc#L6039Link is misaligned?
Expect.throws(() => helper());Do we expect both backends will throw a StackOverflowException and should we narrow this expectation?
helper();An expectation here might make the update more clear.
Expect.throws(() => helper());Should validate the thrown exception is what we actually expect.
Expect.type<Map<String, String>>(v1);
Expect.type<Map<int, int>>(v2);Is there a reason these got moved into a third generation compared to the original test?
// https://github.com/dart-lang/sdk/blob/63622f03eeaf72983b2f4957fa84da8062693f00/runtime/vm/isolate_reload_test.cc#L6065Link is misaligned.
// https://github.com/dart-lang/sdk/blob/63622f03eeaf72983b2f4957fa84da8062693f00/runtime/vm/isolate_reload_test.cc#L6013Link is misaligned.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
6 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: tests/hot_reload/run_new_field_initializers_cyclic_initialization/main.0.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/run_new_field_initializers_super_class/main.0.dart
Insertions: 2, Deletions: 2.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/existing_static_field_changes_type_indirect_function/main.0.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/typedef_add_parameter/main.0.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/typedef_to_not_typedef/main.0.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/run_new_field_initializers_cyclic_initialization/main.1.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/existing_static_field_changes_type_indirect_function/main.1.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/run_new_field_initializers_super_class/main.1.dart
Insertions: 2, Deletions: 2.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/not_typedef_to_typedef/main.0.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/typedef_to_not_typedef/main.1.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/typedef_add_parameter/main.1.dart
Insertions: 2, Deletions: 2.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/not_typedef_to_typedef/main.1.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/run_new_field_initializers_throws/main.1.dart
Insertions: 3, Deletions: 3.
The diff is too large to show. Please review the diff.
```
```
The name of the file: tests/hot_reload/run_new_field_initializers_throws/main.0.dart
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
[ddc] Porting VM hot reload tests to the hot reload framework related to type updates.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Mark ZhouLink is misaligned?
Done
Expect.throws(() => helper());Do we expect both backends will throw a StackOverflowException and should we narrow this expectation?
Done
helper();An expectation here might make the update more clear.
Done
Expect.throws(() => helper());Should validate the thrown exception is what we actually expect.
I added a string check here, which should be sufficient.
Expect.type<Map<String, String>>(v1);
Expect.type<Map<int, int>>(v2);Is there a reason these got moved into a third generation compared to the original test?
It was just easier to express as a 2-tuple vs a 2-tuple then 4-tuple. No major reason - lemme know if you'd prefer it looking more similar.
Mark ZhouLink is misaligned.
Done
Mark ZhouLink is misaligned.
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |