SILGen: When transforming to AnyHashable materialize the value in a temporary #17928
Conversation
…emporary emitAnyHashable expects an address value. rdar://40583597
|
@swift-ci Please test and merge |
…in a temporary emitAnyHashable expects an address value. Cherry-pick from swiftlang#17928. Explanation: When transforming values to AnyHashable we sometimes (e.g tuples of strings) omit converting the value to an address type by storing it to the stack leading to a compiler crash. The fix is to store the value to the stack if it is not already available as an in memory value. Scope: Affects only conversions to AnyHashable. The code seems to stem from 2016. Risk: Low. Code is added that checks that the value expected by emitAnyHashable is already in memory if it is not we store it to memory. Testing: A Swift CI test was added. rdar://40583597
|
@rudkx While the fix is correct, I'm surprised the test case in question emits a function conversion. Any ideas why we wrap the closure literal in a function conversion here, instead of coercing the argument types? |
| // CHECK: apply [[CVT]]<String>(%0, [[ADDR]]) | ||
| func dontCrash() { | ||
| let userInfo = ["hello": "world"] | ||
| let d = [AnyHashable: Any](uniqueKeysWithValues: userInfo.map { ($0.key, $0.value) }) |
There was a problem hiding this comment.
@aschwaighofer I would prefer an explicit function conversion test case, like the rest of the file. It's kind of odd that the type checker picks a function conversion here, instead of converting $0.key and $0.value, and if we fix that the test will no longer be testing the problematic code path.
|
@slavapestov The argument is a |
|
@rudkx it sounds like we're converting a function instead of the argument inside the function. However as you mentioned the tuple conversion won't work either... |
emitAnyHashable expects an address value.
rdar://40583597