Swift 5 LLDB 错误：警告：<EXPR>:12:9：警告：变量“$__lldb_error_result”的初始化从未使用过

Posted 2023-02-15

【中文标题】Swift 5 LLDB 错误：警告：<EXPR>:12:9：警告：变量“$__lldb_error_result”的初始化从未使用过

【英文标题】：Swift 5 LLDB error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used

【发布时间】：2019-09-05 04:31:58

【问题描述】：

完整的错误信息：

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(
    ^~~~~~~~~~~~~~~~~~~~~

当我在通用 UITableViewController (TVC) 中查询 Dictionary<String, String> 属性的值时，此错误出现在控制台中。

更多细节...

我有一个通用 TVC（如上所述），它或多或少基于 Florian Kugler 和 Daniel Eggert 的“核心数据”一书中概述的框架，除其他外，它采用 T 的通用值。

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

此通用 TVC 包含一个字典，旨在保存 TVC 部分标题的较长“替代”名称列表。

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

我选择以这种方式对 TVC 进行编程，因为在数据模型属性（部分标识符）中将名称的引用作为两个短字符 String 比将长名称作为 @987654330 来保存似乎更有效@。

我尝试在代码中的许多不同位置填充这本字典，其中大部分都有效，但结果都相同，特别是：

我使用调试器单步执行代码，正如预期的那样，字典是通过对持久存储的单个提取请求填充的； 紧接着，对控制台的print(dictionarySectionData.description) 调用会按预期打印出正确填充的字典； 在此print 之前和之后立即使用p dictionarySectionData（或po）向控制台询问LLDB，会产生此问题开头处详述的完整错误消息； 同时，Assistant Editor Variable Viewer显示字典为空，与打印出奇的冲突； 我继续单步执行代码来构造 TVC，因为字典不再有其键值对，我无法回忆我的部分标题的值，并且正如预期的那样，控制台报告“致命错误：意外发现 nil 而展开可选值”。

我做了一些简单的研究：

这个 Blog 由 Scott Berrevoets 撰写，标题为“重新绑定自我：调试器的断点”。 Keith Smiley 的 Swift Bug Report 标题为“LLDB：警告：变量‘$__lldb_error_result’的初始化”。 Zev Eisenberg 的 Swift Bug Report 标题为“错误：在 NSAttributedString 扩展中使用未声明的类型 '$__lldb_context'”。

看来我可能有：

偶然发现编译器中的一个错误；或 试图在通用 TVC 中设置字典的值，以便编译器解释重新绑定到自身的尝试？？

坦率地说，根据我对编译器和 Swift 的浅薄知识，我都无法理解这两种方法，这将花费我数月甚至数年的学习和经验。我很高兴随着时间的推移慢慢积累。

我确实有一个令人满意的解决方案...而不是在 TVC 生命周期开始时为 TVC 的部分标题构建一个较长的“替代”名称字典，而是在每次代码解析名称时运行一个获取请求当前的 TVC 部分标题。这可以完美运行并且不会阻塞 UI（目前）。

但是，我不能在开始构建通用 TVC 时运行一次提取来为 TVC 的部分标题准备一个包含较长“替代”名称的简明字典，而是必须为每个部分运行一次提取，这让我非常恼火用户决定滚动浏览的部分。执行一次提取并在内存中保存 12-15 个键值对的字典似乎比运行多次提取更有效。

有人遇到过这个问题吗？

如果是这样，您能提供任何建议吗？

---

更新

问题似乎在于我对明确解包的Optional 的使用——或者更准确地说，是我的误用。

这是我用来填充字典的代码...

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
    

有两个代码元素导致了错误消息...

A.如上func createDictionaryOfSectionHeaderText()

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

...正在将字符串输入格式“%02d”，不确定效果...待定。

（现在从这两行更改为单行 let formatSortOrder = String(format: "%02d", type.sortOrder) - 当然可以。）

B.在UITableViewDelegate 方法内func tableView(_ tableView: UITableView, viewForHeaderInSection section: Int) -> UIView?

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

...经过对此事的更多思考，当显式打开 Optional 时，当 Optional 为 nil 时，这与预期的完全一样！！

因此，当我通过删除显式解包指令将 setter 更改为 stringHeaderText 并在 nil 时提供默认值时，我的编程问题就消失了。

stringHeaderText = dictionarySectionData[stringSectionName] ?? "ERROR"

如果/当我更好地理解这一点时，我什至可以提供答案。

【问题讨论】：

是的，几乎每个po 都会打印出这条消息。在 Xcode 中进行调试总是困难而缓慢，而且每年都会变得更糟。他们得到了一个新关键字v，但这完全没用，因为很多变量都不可用。我讨厌 Xcode :( 与 IntelliJ 相比，Xcode 真的非常糟糕。

@J.Doe 技术说明 - 这与 Xcode 无关，而是与 LLVM 调试器有关。

您能否添加更多与泛型类相关的代码？也许dynamic 或NSManaged 的一些错误用法可能是问题所在？

@Sulthan 感谢您的评论......当然我可以包含代码，但它会是一个非常大的块，至少需要三个类才能在上下文中呈现。所有实体属性都正常运行并使用我提到的项目构建和运行的“令人满意的解决方案”，所以除非我遗漏了什么，我相当肯定它与NSManagedObject 子类/es 无关。 PS 用 Swift 编写，所以不要使用 dynamic。

【参考方案1】：

这些问题应该在 XCode 12 中得到解决。 XCode 10 和 11 中确实存在很多错误，尤其是在泛型方面

【讨论】：

这不是问题的答案！