Closed adrian-prantl closed 1 month ago
@swift-ci test
Proposed test case:
var coin: String
if Bool.random() {
coin = "heads"
} else {
coin = "tails"
}
When I print the string before it's assigned, the output is:
(lldb) p coin
(String) coin = {
_guts = {
_object = (_countAndFlagsBits = 0, _object = 0x0000000000000000)
}
}
Does this patch address this case? If so what is the error message displayed? I wonder if the error should state "unassigned"/"uninitialized" or something else?
Does this patch address this case? If so what is the error message displayed? I wonder if the error should state "unassigned"/"uninitialized" or something else?
The summary (one one machine I tried this on) is
<cannot decode string: memory read failed for 0x18>
but keep in mind that the exact error is going to be random, because we're reading from uninitialized memory.
The reason I don't want to say "unassigned" or "uninitialized" is because the summary formatter really doesn't know that. I have encountered this most often in situations where a field's offset was miscomputed (probably biased because I've been debugging these scenarios a lot) and in such a case, "uninitialized" is just wrong.
However, I could add a special case for an all-zero string?
Done. Your example has a good chance of printing as <uninitialized>
now, depending on whether or not the compiler zeros out the memory first.
@swift-ci test
I agree about eventually adding error handling to the summaries. If these actually were errors, then an IDE could e.g., mark them up graphically different.
@swift-ci test windows
Currently when LLDB encounters an uninitialized string the summary formatter will fail and the user sees something like:
with this patch this becomes