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

提问人:andrewbuilder 提问时间:4/15/2019 最后编辑:andrewbuilder 更新时间:11/25/2020 访问量:5407

问:

完整的错误消息:

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

当我询问泛型 (TVC) 中的属性值时,控制台中会出现此错误。Dictionary<String, String>UITableViewController

更多细节...

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

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

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

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

我选择以这种方式对 TVC 进行编程,因为在数据模型属性(部分标识符)中将对名称的引用作为短两个字符似乎比将长名称作为 .StringString

我尝试在代码中的许多不同位置填充此字典,其中大多数都有效,但结果都相同,具体来说:

  • 我使用调试器单步执行代码,正如预期的那样,字典通过对持久性存储的单个提取请求进行填充;
  • 紧接着,对控制台的调用会按预期打印出正确填充的字典;print(dictionarySectionData.description)
  • 在此之前和之后用(或)询问LLDB进行控制台,将生成此问题开头详述的完整错误消息;p dictionarySectionDatapoprint
  • 同时,Assistant Editor Variable Viewer 显示字典为空,这与打印结果惊人地冲突;
  • 我继续单步执行代码以构造 TVC,因为字典不再具有其键值对,我无法回忆起部分标题的值,并且正如预期的那样,控制台报告“致命错误:在解开可选值时意外发现 nil”。

我做了一些简单的研究:

  1. Scott Berrevoets 的这篇博客的标题为“重新绑定自我:调试器的中断点”。
  2. Keith Smiley 的这份 Swift 错误报告的标题为“LLDB:警告:变量'$__lldb_error_result'的初始化”。
  3. Zev Eisenberg 的这份 Swift 错误报告的标题为“错误:在 NSAttributedString 扩展中使用未声明的类型'$__lldb_context'”。

看来我可能有:

  • 在编译器中偶然发现了一个错误;或
  • 尝试在通用 TVC 中设置字典的值,以便编译器解释重新绑定到 self??

坦率地说,从我对编译器和 Swift 的浅薄了解来看,我都不理解这些,这需要我几个月,甚至几年的学习和经验。我很高兴随着时间的推移慢慢积累。

我确实有一个令人满意的解决方案......我没有在 TVC 生命周期开始时为 TVC 的章节标题构建较长的“替代”名称的字典,而是在每次代码解析当前 TVC 章节标题的名称时运行一个 fetch 请求。这运行良好,并且不会阻止 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
    }
}

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

一个。如上所述func createDictionaryOfSectionHeaderText()

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

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

(现在从那两行改为单行 - 这当然有效。let formatSortOrder = String(format: "%02d", type.sortOrder)

B.在方法中UITableViewDelegatefunc tableView(_ tableView: UITableView, viewForHeaderInSection section: Int) -> UIView?

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

...经过对此事的更多思考,当显式解开 Optional 时,当该 Optional 为 nil 时,这与预期完全一致!!

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

stringHeaderText = dictionarySectionData[stringSectionName] ?? "ERROR"

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

swift uitableview 字典 泛型 lldb

评论

1赞 J. Doe 4/15/2019
是的,几乎每个人都会打印出此消息。在 Xcode 中调试总是困难而缓慢,而且每年都会变得更糟。他们得到了一个新的关键字,但这完全没用,因为很多变量都不可用。我讨厌 Xcode :(与 IntelliJ 相比,Xcode 真的非常糟糕。pov
4赞 Sulthan 4/15/2019
@J.Doe 技术说明 - 这与 Xcode 无关,而是与 LLVM 调试器有关。
0赞 Sulthan 4/15/2019
您能否添加更多与泛型类相关的代码?也许有些错误的用法或可能是问题所在?dynamicNSManaged
0赞 andrewbuilder 4/15/2019
@Sulthan感谢您的评论...当然,我可以包含代码,但要能够在上下文中呈现,至少要跨三个类,这将是一个非常大的块。所有实体属性都正常运行,并使用我提到的项目 Builds and Runs 的“令人满意的解决方案”,因此除非我遗漏了什么,否则我相当确定它与子类无关。PS 用 Swift 编写,所以没有使用 .NSManagedObjectdynamic

答:

-2赞 Skwiggs 11/25/2020 #1

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

评论

2赞 Abhishek 6/15/2021
这不是问题的答案!