Swift 5 LLDB error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used

Question

Full Error Message:

error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

error: <EXPR>:19:5: error: use of unresolved identifier '$__lldb_injected_self'
    $__lldb_injected_self.$__lldb_wrapped_expr_7(
    ^~~~~~~~~~~~~~~~~~~~~

This error appears in Console when I interrogate the value of a Dictionary<String, String> property within a generic UITableViewController (TVC).

More Detail...

I have a generic TVC (noted above) that is more or less based on the framework outlined in the book "Core Data" by Florian Kugler and Daniel Eggert and takes, amongst other things, a generic value of T.

class TVCDataSource_List<T: Managed, etc...>

This generic TVC includes a dictionary that is designed to hold a list of longer 'alternative' names for the TVC's section headers.

var dictionarySectionData: [String: String] = [:]

I've elected to program the TVC this way because it seems more efficient to hold a reference to a name as a short two character String in the data model attribute (section identifier) than a long name as a String.

I've tried populating this dictionary at many different places in code, most of which work but all with the same outcome, specifically:

• I step through the code using the debugger and, as expected, the dictionary is populated via a single fetch request to the persistent store;
• Immediately following, a call to print(dictionarySectionData.description) to the console, prints out a properly populated dictionary, as expected;
• Interrogating LLDB with p dictionarySectionData (or po) immediately before and after this print to console, produces the Full Error Message detailed at the start of this question;
• At the same time, the Assistant Editor Variable Viewer shows the dictionary to be empty, which surprisingly conflicts with the print;
• I continue to step through the code to construct the TVC, as the dictionary no longer has its key value pairs, I cannot recall the value for my section header and as expected, the console reports "Fatal error: Unexpectedly found nil while unwrapping an Optional value".

I've done a bit of simple research:

1. This Blog by Scott Berrevoets titled "Re-binding self: the debugger's break(ing) point".
2. This Swift Bug Report by Keith Smiley titled "LLDB: warning: initialization of variable '$__lldb_error_result'".
3. This Swift Bug Report by Zev Eisenberg titled "error: use of undeclared type '$__lldb_context' in NSAttributedString extension".

It seems that I may have either:

• stumbled across a bug in the compiler; or
• attempted to set the value for the dictionary within the generic TVC such that the compiler interprets an attempt to re-bind to self??

Frankly neither of which I understand and from my shallow knowledge of the compiler and Swift, would take me months, possibly years of learning and experience. Which I'm happy to slowly accumulate over time.

I do have a satisfactory solution... instead of building a dictionary of the longer 'alternative' names for the TVC's section headers at the beginning of the TVC lifecycle, I run a fetch request EACH TIME the code resolves the name for the current TVC section header. This works perfectly and does not block the UI (yet).

However, it really annoys me that I cannot run one fetch at the start of the construction of my generic TVC to prepare a concise dictionary of longer 'alternative' names for the TVC's section headers and instead have to run a fetch for each section that the user decides to scroll through. To perform one fetch and hold a dictionary of 12-15 key value pairs in memory seems far more efficient that running many fetches.

Has any one experienced this problem?

If so, are you able to offer any advice?

---

UPDATE

The problem seems to be with my use - or perhaps more correctly, my misuse - of the explicitly unwrapped Optional.

Here is the code I use to populate the dictionary...

func createDictionaryOfSectionHeaderText() {

    let request = Types.preparedFetchRequest
    // noting .preparedFetchRequest is a static var, available through generics

    let key = "typeParent.typeParentName"
    let name = "Taxonomy"
    let predicate = NSPredicate(format: "%K == %@", argumentArray: [key, name])

    request.predicate = predicate

    var results: [Types] = []

    do {

        results = try <<My NSManagedObjectContext>>.fetch(request)
    }
    catch {

        let fetchError = error
        print(fetchError)
    }

    for type in results {

        let formatSortOrder = String(format: "%02d", type.sortOrder)
        dictionarySectionData[formatSortOrder] = type.typeName
    }
}

There were two elements of code that caused the error message...

A. As above in the func createDictionaryOfSectionHeaderText()

let stringSortOrder = String(type.sortOrder)
let formatSortOrder = String(format: "%02d", stringSortOrder)

...which was feeding a string into the format "%02d", uncertain of the effect... TBA.

(Now changed from those two lines to the single let formatSortOrder = String(format: "%02d", type.sortOrder) - which of course works.)

B. Within the UITableViewDelegate method func tableView(_ tableView: UITableView, viewForHeaderInSection section: Int) -> UIView?

stringHeaderText = dictionarySectionData[stringSectionName]!
// "Fatal error: Unexpectedly found nil while unwrapping an Optional value"

...which, following more thought on the matter, is exactly as expected when explicitly unwrapping the Optional, when that Optional is nil!!

So, when I change the setter to stringHeaderText by removing the instruction to explicitly unwrap, and instead offer a default value when nil, my programming problem disappears.

stringHeaderText = dictionarySectionData[stringSectionName] ?? "ERROR"

I may even provide an answer if/when I understand this better.

Answer 1

These issues should be solved in XCode 12. There were indeed a lot of bugs in XCode 10 & 11, especially when it came to Generics