> > /// ...In the future we may wish to switch to a > > > /// registration mechanism where new error types can be registered at > > > /// runtime instead of a hard coded scheme.
I immediately regret my decision to copy-paste from terminal. :/ - Lang. On Sun, Apr 30, 2017 at 10:39 AM, Lang Hames <lha...@gmail.com> wrote: > Hi Zachary, > > I'm new to LLDB so take my opinion with a grain of salt, but this sounds > like a good idea to me. LLDB is likely to encounter more and more LLVM APIs > using llvm::Error in the future, so renaming lldb_private::Error to reduce > confusion seems sensible. > > Replacing lldb_private::Error at some point in the future probably makes > sense too. The author of lldb_private::Error seems to have had a similar > idea: > > /// ...In the future we may wish to switch to a > > > /// registration mechanism where new error types can be registered at > > > /// runtime instead of a hard coded scheme. > > The challenge here will be interoperability with the python APIs, which > look like they map the current lldb_private::Error into Python. That will > take some thought, but I think it should be possible. > > For any LLDB devs who are interested in llvm::Error, the lightning talk > that introduced it is at: https://www.youtube.com/watch?v=Wq8fNK98WGw , > and the API is covered in more detail in the LLVM programmer's manual: > http://llvm.org/docs/ProgrammersManual.html#recoverable-errors . > > Cheers, > Lang. > > On Fri, Apr 28, 2017 at 8:40 PM, Zachary Turner <ztur...@google.com> > wrote: > >> I have a patch locally that renames lldb_private::Error to >> lldb_private::LLDBError. As you might expect, this is a pretty large patch >> so I don't plan to put it up for review, but since it's kind of a >> fundamental class I figured I should at least start a discussion. >> >> The primary motivation for this is to enable cleaner interop between >> lldb's Error class and llvm::Error. Currently there is an ambiguity >> between the two. Obviously they are scoped in different namespaces, but >> it's still confusing when looking at code to see such similarly named >> classes. >> >> There are a number of advantages to llvm::Error over lldb Error which I'm >> happy to elaborate on if anyone needs some clarification (I've also cc'ed >> lang on here, who wrote the original llvm Error implementation). >> >> Long term I would eventually like to deprecate lldb's Error class >> entirely, and switch entirely to llvm::Error. An intermediate transition >> phase would likely involve making something like LLDBWrapError which >> interoperates with llvm::Error and wraps an lldb_private::LLDBError. >> >> For now though, I'm only proposing a very simple rename with minimal >> invasiveness. >> >> Comments? >> > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
