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

Jump to bottom

[SR-6286] AnyHashable casting error in Swift 3.2/Swift 4 #48836

Closed
swift-ci opened this issue Nov 2, 2017 · 1 comment
Closed

[SR-6286] AnyHashable casting error in Swift 3.2/Swift 4 #48836

swift-ci opened this issue Nov 2, 2017 · 1 comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Nov 2, 2017

Previous ID SR-6286
Radar rdar://problem/34824398
Original Reporter eholley (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

  • Xcode 9.0.0 with Swift 3.2/4.0

  • Xcode 9.0.1 with Swift 3.2/4.0

  • Xcode 9.1.0 with Swift 3.2/4.0

  • Xcode 9.2.0 Beta with Swift 3.2/4.0

Additional Detail from JIRA
Votes 1
Component/s Compiler, Standard Library
Labels Bug, Miscompile
Assignee None
Priority Medium

md5: f4c2c8bdd4af3e711bf7d1c2f26ae7e8

Issue Description:

Summary

I posted this as a radar on Oct. 4th, but haven't seen any motion on it. I've already factored out AnyHashable from our codebase; but, would like to reintroduce it as removing it created more complexity.

Swift 3.1: Behaves as expected.

Swift 3.2/Swift 4: AnyHashable's casting behavior fails with Swift classes. Structs and NSObject classes behave correctly.

Steps to Reproduce

  1. Create two Swift classes, conforming to Hashable.

  2. Instantiate two AnyHashable objects, each using a different object type (from Redundant Load Elimination Patches #1).

  3. Cast an AnyHashable object to the other's class type.

  4. Result should be nil.

Example

class SwiftClass3 : Hashable { ... }
class SwiftClass4 : Hashable { ... }
let c3 = SwiftClass3()
let c4 = SwiftClass4()
let h3: AnyHashable = c3
let h4: AnyHashable = c4

Expected results:

XCTAssertTrue(h3 is SwiftClass3)
XCTAssertFalse(h3 is SwiftClass4)
XCTAssertFalse(h4 is SwiftClass3)
XCTAssertTrue(h4 is SwiftClass4)
XCTAssertNotNil(h3 as? SwiftClass3)
XCTAssertNil(h3 as? SwiftClass4)
XCTAssertNil(h4 as? SwiftClass3)
XCTAssertNotNil(h4 as? SwiftClass4)

Actual results, Swift 3.2/4.0 is incorrect:

XCTAssertTrue(h3 is SwiftClass3)
XCTAssertFalse(h3 is SwiftClass4) // **** swift 3.2/4.0: incorrect ****
XCTAssertFalse(h4 is SwiftClass3) // **** swift 3.2/4.0: incorrect ****
XCTAssertTrue(h4 is SwiftClass4)
XCTAssertNotNil(h3 as? SwiftClass3)
XCTAssertNil(h3 as? SwiftClass4) // **** swift 3.2/4.0: incorrect ****
XCTAssertNil(h4 as? SwiftClass3) // **** swift 3.2/4.0: incorrect ****
XCTAssertNotNil(h4 as? SwiftClass4)
@tbkka
Copy link
Contributor

tbkka commented Jan 29, 2020

I just tried to reproduce this in Xcode 11.1 and it seems to be working correctly now. Can you please re-test and let us know?

@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
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself standard library Area: Standard library umbrella
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@swift-ci @tbkka