Skip to content

Kotlin: extract called private methods of specialised types, and specialised instances of anonymous types#10853

Merged
smowton merged 6 commits intogithub:mainfrom
smowton:smowton/fix/specialised-anon-classes
Oct 19, 2022
Merged

Kotlin: extract called private methods of specialised types, and specialised instances of anonymous types#10853
smowton merged 6 commits intogithub:mainfrom
smowton:smowton/fix/specialised-anon-classes

Conversation

@smowton
Copy link
Copy Markdown
Contributor

@smowton smowton commented Oct 17, 2022

No description provided.

@smowton smowton requested review from a team as code owners October 17, 2022 10:29
@smowton smowton added the no-change-note-required This PR does not need a change note label Oct 17, 2022
tamasvajk
tamasvajk previously approved these changes Oct 17, 2022
Copy link
Copy Markdown
Contributor

@tamasvajk tamasvajk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks plausible to me.

}

private fun signatureOrWarn(t: TypeResult<*>, associatedElement: IrElement) =
t.signature ?: "<signature unavailable>".also { logger.warnElement("Needed a signature for a type that doesn't have one", associatedElement) }
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this going to unify things that should be distinct? (because they both map to the same <signature unavailable> string?

If so, would we be better off just not extracting associatedElement instead?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should only happen if an anonymous type occurs in a function's parameter list, which ought to be impossible. The magic string is also what we used to do in that circumstance; I've just had to move the code to where the signature is used rather than where it is produced.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Groan, turns out Kotlin can refer to anonymous types in parameter context: for example, within an object : SuperType { ... } declaration I can take a function reference this::f, which will capture this, synthesising a class implementing FunctionX with a constructor that takes an anonymous parameter type. Such refs will currently generate a warning that we can't produce a proper signature for that method, but we always got this wrong silently, so I think it's probably better to have it produce the warning and try to figure out what if anything to do about this later rather than re-silence the warning.

@smowton smowton merged commit c6b62c9 into github:main Oct 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Java Kotlin no-change-note-required This PR does not need a change note

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants