[SR-6290] Bad Int values shown in Xcode variable view when viewing Dictionary with enum keys

[swift-ci]

Previous ID	SR-6290
Radar	rdar://problem/35337096
Original Reporter	igz (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Attachment: Download

Additional Detail from JIRA

Votes	0
Component/s	LLDB for Swift
Labels	Bug
Assignee	@keith
Priority	Medium

md5: ea795ebb805bae527b2ecf72fb3ccfc7

Issue Description:

Bad integer values are shown in Xcode's variable view when inspecting dictionaries with string-based enum keys. Correct values are shown when the keys are created with the enum cases' rawValues.

Contrary to what the variable view shows, the actual values do match the input.

[belkadan]

@swift-ci create

[keith]

The root of this issue appears to be that the byte offsets that are calculated here https://github.com/apple/swift-lldb/blob/stable/source/Symbol/SwiftASTContext.cpp#L501-L521 are wrong. In this repro case where we have an enum for the dictionary keys, and an int for the values, the tuple created by SwiftHashedContainer has 9 bytes, the first 1 for the enum, and the other 8 for the int. Yet the offsets calculated here are 0, and 8 instead of 0 and 1. This leads us to print this garbage data instead. I'm still not entirely sure why this only affects the dictionary case, and not just any tuple with an enum and an int (the offsets in that case are also 0 and 8, but it prints correctly), but I'm still looking into that.

[keith]

Ok so this appears to be the case because the bytes for the key of the tuple are padded in the case of defining a tuple by itself, but they're not padded in the case they're in a dictionary. This results in the expected size of the tuple type generated by lldb to be 16 bytes, yet the data given to it is only 9 bytes. It actually seems like the solution here should be padding the key, instead of getting a different offset for the type.

[keith]

I've submitted a fix for this and would love feedback on it! apple/swift-lldb#259

[keith]

I'm still trying to debug the test failure that seems to be caused by my fix. In the meantime I've submitted a separate PR to add some tests around this use case. Currently this specific bug's test is disabled (until a fix is merged), but some related cases have been added. apple/swift-lldb#262

[keith]

Fixed in apple/swift-lldb#259