-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Kotlin: Enable java/misnamed-type query #11436
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
Conversation
We used to get alerts for the class around a local function, a lambda, or a function reference, which we give name "". Now those are marked as compiler-generated, and the query ignores compiler-generated types.
efe9744
to
a423f5f
Compare
private fun extractGeneratedClass( | ||
localFunction: IrFunction, | ||
superTypes: List<IrType>, | ||
compilerGeneratedKind: CompilerGeneratedKinds? = null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a case when extractGeneratedClass
is called and the class should be non compiler generated? Should this parameter be nullable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that any class extracted by "extractGeneratedClass" should be treated as compiler-generated. As in the other comment, null
here really means "the default".
val compilerGeneratedKind = if (s.origin == IrDeclarationOrigin.ADAPTER_FOR_CALLABLE_REFERENCE) { | ||
CompilerGeneratedKinds.DECLARING_CLASSES_OF_ADAPTER_FUNCTIONS | ||
} else { | ||
null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels unintuitive for me that we pass null
, but in the end it becomes CompilerGeneratedKinds.CALLABLE_CLASS
. Should we instead explicitly specify the latter here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered that, but then we'd have to repeat CALLABLE_CLASS
in 3 places. I think of the null here as "no special value; just use the default". Perhaps I should have called it compilerGeneratedKindOverride
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Another option would be specifying a default parameter value. But compilerGeneratedKindOverride
also sounds reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with a default parameter value is I think I'd need to specify it for both overloads of the function, as well as passing it as a parameter in the call that makes use of the "last argument is a block" syntax. So I've gone with the ...Override
name to avoid repeating it.
We used to get alerts for the class around a local function, a lambda, or a function reference, which we give name "". Now those are marked as compiler-generated, and the query ignores compiler-generated types.