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-13042] Optional promotion and pointers can interact in unexpected ways #55488

Open
PeterAdams-A opened this issue Jun 18, 2020 · 1 comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@PeterAdams-A
Copy link

Previous ID SR-13042
Radar rdar://problem/64953115
Original Reporter @PeterAdams-A
Type Bug
Additional Detail from JIRA
Votes 0
Component/s
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: 246d265bee81c5a9861926f83f62154f

Issue Description:

When combining overloaded functions, optionals and pointer types sometimes the function selected is not the one I would have expected as demonstrated in the following code fragment which does not compile.

func id(_ arg: UnsafeMutablePointer<Int32>?) -> UnsafeMutableBufferPointer<Int32>? { 
    return .init(start: arg, count: 1) 
}

func id(_ arg: UnsafePointer<Int32>?) -> UnsafeBufferPointer<Int32>? { 
    return .init(start: arg, count: 1) 
}

func ohSwift(_ arg: UnsafePointer<Int32>?) -> UnsafeBufferPointer<Int32>? { 
    return .init(start: arg, count: 1) 
}

let ptr: UnsafeMutablePointer<Int32> = .allocate(capacity: 1)
 _ = ohSwift(ptr)    // This shows that we can pass a UMP to a UP
 var other = id(ptr) // Here it'll _PREFER_ the UP? version over the UMP?
                     // version despite the fact we're passing an UMP
 other!.baseAddress!.pointee = 3 // Which is why this fails.

I would have expected calling id with a UMP to favour the UMP? version over the UP? version not the reverse.

Adding type hints on the call or the return type or alternatively using .some(ump) on the call explicitly allows the above code to compile.

@typesanitizer
Copy link

Confirming this reproduces on master. It would be a breaking change to change the behavior here... that said Slava says that this is probably unintentional.

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the compiler The Swift compiler in itself label Dec 13, 2022
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 in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants