Skip to content

Fix bug conversions of function returning function failed #82398

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

kntkymt
Copy link
Contributor

@kntkymt kntkymt commented Jun 22, 2025

Description

resolves #82397

let a: () -> () -> Void = {{}}
let _: (() -> () -> Void)? = a // 🔴 Cannot convert value of type '() -> Void' to specified type '() -> () -> Void'

regression of #78377

- if (convertTo->is<FunctionType>())
+ if (convertTo->is<FunctionType>() && !resultType->is<FunctionType>())
    return false;

Since the new condition doesn’t handle the case where both lhs and rhs have the same curry levels, conversions of function-returning functions are incorrectly repaired by repairByInsertingExplicitCall. It should be resolved by ValueToOptionalConversion by returning false in repairByInsertingExplicitCall.

Solution

improve guard condition at repairByInsertingExplicitCall, specially: check curry levels of lhs and rhs. if lhs doesn't have more curry levels than rhs, it shouldn't be repaired by InsertingExplicitCall.

note that since the existing logic (!resultType->is<FunctionType>()) is designed to ensure that

  • lhs has 2 (or more) curry levels and
  • rhs has 1 (or more) curry level

, The new guard logic (lhs.curryLevels <= rhs.curryLevels) include this existing logic.

// the source must have more curry levels.
if (auto convertToFnType = convertTo->getAs<FunctionType>()) {
if (fnType->getNumCurryLevels() <= convertToFnType->getNumCurryLevels())
return false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry but I don't think this is the right fix. Before attempting this repair we need to make sure that there are no restrictions recorded (other locations in repairFailures do it with hasAnyRestriction) otherwise we end up in a situation like this where the fix is greedily applied before optional injection could be attempted (if that was allowed to proceed the types would line up exactly).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for quick review!

we need to make sure that there are no restrictions recorded

I see, it sounds like related to the overall flow of reparingByInserting, it may be difficult for me to fix it 😅 let me close this PR and leave to owners 🙇 (Since I'm still a beginner of compiler)

@kntkymt kntkymt closed this Jun 23, 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.

Conversions of Function returning function fail in 6.2
2 participants