| Code-Review | +1 |
I like this. I prefer the word "provenance" that you've used in discussions, but that's a little long (and perhaps obscure) for the API. "Origin" seems fine.
| 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. |
| Code-Review | +1 |
/// Whether the constructor is from an explicit [FieldDeclaration],property?
/// Whether the constructor is from a getter or setter.property?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This CL is too large for me to be able to code review effectively. My personal opinion is that it would be good engineering practice to split it up into two CLs: one that adds the new functionality but preserves test expectations (adjusting the element printer if necessary), and a follow-up CL that updates the element printer and the test expectations.
My rationale for suggesting this split is that it would be much easier to argue that the two CLs are safe: the first would be clearly safe because it wouldn't contain any test expectation changes, and the second would be clearly safe because it would contain only test changes.
But since others have already given you +1s, if you want to go ahead and land it on the strength of others' review, I won't try to stop you.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
/// Whether the constructor is from an explicit [FieldDeclaration],Konstantin Shcheglovproperty?
Done
/// Whether the constructor is from a getter or setter.Konstantin Shcheglovproperty?
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This CL is too large for me to be able to code review effectively. My personal opinion is that it would be good engineering practice to split it up into two CLs: one that adds the new functionality but preserves test expectations (adjusting the element printer if necessary), and a follow-up CL that updates the element printer and the test expectations.
My rationale for suggesting this split is that it would be much easier to argue that the two CLs are safe: the first would be clearly safe because it wouldn't contain any test expectation changes, and the second would be clearly safe because it would contain only test changes.
But since others have already given you +1s, if you want to go ahead and land it on the strength of others' review, I won't try to stop you.
I agree, just implementation without changes to the text output, specifically without writing new flags, is useful. See https://dart-review.googlesource.com/c/sdk/+/465663 that I made post factum.
| 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. |
5 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: pkg/analyzer/lib/dart/element/element.dart
Insertions: 2, Deletions: 2.
The diff is too large to show. Please review the diff.
```
DeCo. Add PropertyInducingElement.isOriginDeclaration, isOriginGetterSetter; FieldElement.isOriginDeclaringFormalParameter, isOriginEnumValues.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |