| Code-Review | +1 |
I can't think of what purpose an extension type would serve, if its representation field is never referenced.
I can't either, but if the type implements the representation type then members on `this` can be implicitly invoked. Not sure whether that gets counted as a reference by our implementation.
correctionMessage: Try removing the '' keyword to avoid declaring a field, or try using the field, or removing it.Is this intended to have a parameter containing the keyword?
If the parameter is still necessary, but the associated field is not, trynit: "try" --> "then"
Also, consider including the example code with the fix applied (for all three fixes).
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
correctionMessage: Try removing the '' keyword to avoid declaring a field, or try using the field, or removing it.Is this intended to have a parameter containing the keyword?
Haha it was! Thanks for catching; I've added some logic.
If the parameter is still necessary, but the associated field is not, trynit: "try" --> "then"
Also, consider including the example code with the fix applied (for all three fixes).
| 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. |
lgtm. Your call on whether to address my code review comment.
// We take a hands-off approach to reporting unused private representationThis comment isn't clear to me in isolation. Looking at the commit message, I think what you're saying is that we don't report an extension type representation field as unused because (a) it's not likely to arise in practice, and (b) it's not possible to remove the unused field. Consider saying this more directly.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// We take a hands-off approach to reporting unused private representationThis comment isn't clear to me in isolation. Looking at the commit message, I think what you're saying is that we don't report an extension type representation field as unused because (a) it's not likely to arise in practice, and (b) it's not possible to remove the unused field. Consider saying this more directly.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
lgtm
| 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. |
analyzer: Report unused fields with origin in a primary constructor
Work towards https://github.com/dart-lang/sdk/issues/62248
In this change, we exclude fields declared in a primary constructor
which is declared in an extension type. Since the representation field
is required, the corrective action is unclear. (I can't think of what
purpose an extension type would serve, if its representation field is
never referenced. But users are creative.)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |