-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Declaration isn't referenced
review for abstract private declarations
#54374
Comments
I'm a little confused about the question, but we can dig in.
I don't really understand what your comment is about The thread gets too spread out for me after that. 😄 . I won't address your comments about |
It is called at class A with N {
void fn() {
_fn();
}
@override
void _fn() {}
}
This one is working as intended, added it there as a reference (more explanations below).
The difference is that while My point here was: that while
Sorry about that, didn't mean for it to have so many questions and examples in one case. This issue should probably be split into more than one, if you can help me reason it to make sure that the questions are clearer I'd really appreciate it. |
class A with N {
void fn() {
_fn();
}
@override
void _fn() {}
}
|
Yeah I think "unused mixin" is something we haven't really looked into. Could be a reasonable diagnostic. |
I see that, but also there is no way for me to call For me, as a user, it doesn't seem like the lint should be triggered there. Only if it was never implemented anywhere (in the case of Edit: Since it can only be used inside the same library, in my company and personal projects we use this kind of declaration to help us remember some specific names for methods when we want one of our related classes to do a specific inner processing and don't want that to be visible to the rest of the code since maybe calling that somewhere else could potentially cause some confusion or even break something. |
This, IMO should be considered only for private classes/mixins that are implemented, or mixed-in that have only private declarations that are not being called anywhere. I'll take some time to create better (and simpler hahaha) examples than the ones presented above and create a new issue mentioning this one then. |
No, I think
Ah yes, if it is acknowledged dead code for documentation purposes, then it can be marked with |
Thanks a lot for helping me with these questions. I'll create the new issue for unused mixins now. |
Interesting! @srawlins, perhaps you could comment on the following? (Yes, I know this issue has been closed, but let me just revisit one thing... ;-) The notion of being unused is important here, and it is indicated here that Indeed, I haven't noticed any locations in that example where In this case we don't even have that. So surely we could just delete I'd still say "not necessarily", because So, @srawlins, do you think we need to broaden the notion of being "used" slightly, such that an abstract declaration is considered "used" even in the case where it isn't used for any other purpose than being overridden? We could still delete that abstract declaration without breaking any code, but we would eliminate the consistency constraint that is expressed via the requirement that other declarations need to be a correct override of this one. We could be more strict and say that an abstract declaration is only considered to be used based on overrides if it is overridden by at least two declarations (because otherwise it isn't enforcing consistency). |
Thank you for bringing my words to a reasonable request. That is exactly what I was wondering but wasn't able to make a concise explanation for it. |
Declaration isn't referenced
review for private membersDeclaration isn't referenced
review for abstract private declarations
Then this can be ignored with
No, this is not in the purview of unused code detection. There is not a technical reason for What would be the downside of allowing If there is a desire to keep around unused code for some other purpose (other than "use"), like idiomatic unused parameters, then |
@srawlins wrote:
I'm a little bit confused about what it takes for code to be "unused". Would we consider class SomeTypeAnnotationWhichIsRatherVerbose {}
class AnotherTypeAnnotationWhichIsRatherVerbose {}
class YetAnotherTypeAnnotationWhichIsRatherVerbose {}
abstract class _A {
SomeTypeAnnotationWhichIsRatherVerbose _m(
AnotherTypeAnnotationWhichIsRatherVerbose x,
YetAnotherTypeAnnotationWhichIsRatherVerbose y,
);
}
class _B implements _A {
@override
_m(x, y) {....}
}
class _C implements _A {
@override
_m(x, y) {....}
} You could say that If we're just considering to remove the member declaration |
Yes,
That's true! In that case, I would suggest using |
Oh, I was assuming that It's just
Right, I'm just thinking that an override relationship might be considered to be "usage", especially in the case where it involves override inference. |
This is exactly what I was thinking. Thank you for expressing that for me. |
Edit:
See #54374 (comment) for a better explanation of what this issue is about.
Old:
Describe the issue
In the below example, I'd like for someone to please explain to me why this lint is being triggered in
N._fn
, since it is a protected method that can only be called from within a library, this lint should potentially know that.Also, in a class like
C
, I'm not sure this should be triggered. However, I'm not aware if this lint can be aware of other members in the super method it is being overridden, because if it is aware, of them, then inC
I don't believe it should be triggered. Still, probably inD
but that would also bring a question as to why would this be called and not maybe warn that the mixin is unused instead.Maybe the "
Unused-Mixin
" could be called when the mixin is a private mixin like inE
?To Reproduce
Additional context
I'm really out of my depth here, but maybe someone can help me make my questions clearer.
The text was updated successfully, but these errors were encountered: