yinghuitan added a comment. > Does this by any chance have something to do with the fact that there are now > two compile unit lists (one in the actual symbol file, and one in the > wrapping ondemand class?
Yes, that's the major reason. We also need make SymbolFileOnDemand friend in SymbolFile so that SymbolFileOnDemand can call/forward protected virtual methods of `SymbolFile` during overriding. > Would it be possible to avoid that by making SymbolFile a stateless interface? What part do you want to avoid? We could do that by creating a new `SymbolFileReal` class, but we still have to make these compile unit lists methods virtual in `SymbolFile` class so that, like, calling `SymbolFile::GetCompileUnitAtIndex()` can be overridden by `SymbolFileReal`(touching data fields) and `SymbolFileOnDemand` (forwarding to real impl), right? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121631/new/ https://reviews.llvm.org/D121631 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
