| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
final List<Object>? typedefNameFromTearOff = extractTypedefNameFromTearOff(Could you change `extractTypedefNameFromTearOff` to return a record `({String typedefName, Name constructorName})` instead? This call site could definitely benefit from it.
constructorNameFromTearOff ?? (typedefNameFromTearOff![1] as Name).text;The code will never find a `target` from the `typedefNameFromTearOff`; if `node` is a typedef tear-off it has no enclosing class and it will not have an extensionTypeDeclaration.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
final List<Object>? typedefNameFromTearOff = extractTypedefNameFromTearOff(Could you change `extractTypedefNameFromTearOff` to return a record `({String typedefName, Name constructorName})` instead? This call site could definitely benefit from it.
Done
constructorNameFromTearOff ?? (typedefNameFromTearOff![1] as Name).text;The code will never find a `target` from the `typedefNameFromTearOff`; if `node` is a typedef tear-off it has no enclosing class and it will not have an extensionTypeDeclaration.
Right, the test cases are likely passing due to `target==null` fallback below it.
Do we have a way of finding the typedef and then the type it is resolving to? Or are we better off using the fallback below?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
constructorNameFromTearOff ?? (typedefNameFromTearOff![1] as Name).text;Daco HarkesThe code will never find a `target` from the `typedefNameFromTearOff`; if `node` is a typedef tear-off it has no enclosing class and it will not have an extensionTypeDeclaration.
Right, the test cases are likely passing due to `target==null` fallback below it.
Do we have a way of finding the typedef and then the type it is resolving to? Or are we better off using the fallback below?
You can use the `typedefName` returned from `extractTypedefNameFromTearOff` to search through typedefs in the same library. A `Typedef` node has a `type` property that holds its definition, so you can get the target type from `typedef.type.unalias`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
constructorNameFromTearOff ?? (typedefNameFromTearOff![1] as Name).text;Daco HarkesThe code will never find a `target` from the `typedefNameFromTearOff`; if `node` is a typedef tear-off it has no enclosing class and it will not have an extensionTypeDeclaration.
Johnni WintherRight, the test cases are likely passing due to `target==null` fallback below it.
Do we have a way of finding the typedef and then the type it is resolving to? Or are we better off using the fallback below?
You can use the `typedefName` returned from `extractTypedefNameFromTearOff` to search through typedefs in the same library. A `Typedef` node has a `type` property that holds its definition, so you can get the target type from `typedef.type.unalias`.
| 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. |
9 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
[record_use] Constructor invocations via typedefs
Closes: https://github.com/dart-lang/native/issues/2907
TEST=pkg/compiler/test/record_use/record_use_test.dart
TEST=pkg/dart2wasm/test/record_use_test.dart
TEST=pkg/vm/test/transformations/record_use_test.dart
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |