Skip to content
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

[SR-11429] Don't look through CoerceExprs in markDirectCallee #53830

Closed
hamishknight opened this issue Sep 6, 2019 · 2 comments
Closed

[SR-11429] Don't look through CoerceExprs in markDirectCallee #53830

hamishknight opened this issue Sep 6, 2019 · 2 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself type checker Area → compiler: Semantic analysis

Comments

@hamishknight
Copy link
Contributor

Previous ID SR-11429
Radar None
Original Reporter @hamishknight
Type Bug
Status Closed
Resolution Done
Environment

Swift version 5.1-dev (LLVM c5340df2d1, Swift c14addb448)
Target: x86_64-apple-darwin18.5.0

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee @hamishknight
Priority Medium

md5: d962ddabfd7e73fdea14cccf6fc21979

Issue Description:

Currently in markDirectCallee, we look through CoerceExprs when marking a callee as being directly applied. However the fact that it gets marked as being directly applied means that any functions with argument labels cannot be used with a coercion to a user-written function type:

func foo(x: Int) {}
(foo as (Int) -> ())(5)
// error: Cannot convert value of type '(Swift.Int) -> ()' to type '(Swift.Int) -> ()' in coercion

This is because function types written by the user cannot include argument labels.

The only way to get code like this to compile is to let the compiler infer the type in the coercion through a generic type alias, which allows the argument label to be propagated:

typealias Magic<T> = T

func foo(x: Int) {}
(foo as Magic)(x: 5) // Legal.

But I would hope that nobody is actually writing code like this.

In addition, trying to rely on the fact that the referenced function within the coercion is marked as being directly applied in order to get an implicit IUO unwrap currently crashes ([SR-10492]):

func foo() -> Int! {}
(foo as () -> Int)()

And I can't immediately think of any other compelling examples that would break if we were to stop looking through CoerceExprs in markDirectCallee.

@airspeedswift
Copy link
Member

@swift-ci sync

@swift-ci
Copy link
Contributor

Comment by Joseph Twomey (JIRA)

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants