Skip to content

Conversation

@noti0na1
Copy link
Member

@noti0na1 noti0na1 commented Dec 2, 2025

Try to fix #24573, not sure if this is a correct fix.

Try a more strict check for platform SAM

// Superaccessors already show up as abstract methods here, so no test necessary
cls.typeRef.fields.isEmpty &&
// LambdaMetafactory can't handle SAMs with Unit return type unless it's a FunctionN itself
!cls.typeRef.possibleSamMethods.exists(_.info.resultType.isRef(defn.UnitClass))
Copy link
Member

Choose a reason for hiding this comment

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

No this is not the correct fix. LMF can handle Unit result types all right.

It cannot handle the conflicting requirements of having both Unit and non-Unit, because of a bridge.

@noti0na1
Copy link
Member Author

noti0na1 commented Dec 2, 2025

Still WIP

@noti0na1 noti0na1 changed the title Try to fix #24573: Don't treat SAM class with Unit result type as a platform SAM Try to fix #24573: Don't treat SAM class with imcompatible Unit result types as a platform SAM Dec 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Runtime LambdaConversionException failure for valid lambda invocation

2 participants