I think it should be fairly easy to keep interoperability with SBError. SBError just wraps an lldb_private::Error, so as long as we can construct some implementation of ErrorInfoBase from an SBError, we should be good to go. As an extreme example, we could keep LLDBError exactly as is and provide an ErrorInfoBase implementation that wraps it, but keep it around only for compatibility but be deprecated otherwise. Obviously we can do better than this, but the point is it's not a big obstacle <br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 30, 2017 at 10:41 AM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.800000190734863px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace">/// ...In the future we may wish to switch to a <br></font><font face="monospace, monospace">/// registration mechanism where new error types can be registered at <br></font><font face="monospace, monospace">/// runtime instead of a hard coded scheme.</font></blockquote><div><br></div></div></div><div dir="ltr"><div style="font-size:12.800000190734863px"><div>I immediately regret my decision to copy-paste from terminal. :/</div></div></div><div dir="ltr"><div style="font-size:12.800000190734863px"><div><br></div><div>- Lang.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 30, 2017 at 10:39 AM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Zachary,<div><br></div><div>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.<br></div><div><br></div><div>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:</div><div><br></div><div><div><font face="monospace, monospace">/// ...In the future we may wish to switch to a </font></div><div><font face="monospace, monospace">/// registration mechanism where new error types can be registered at </font></div><div><font face="monospace, monospace">/// runtime instead of a hard coded scheme.</font></div></div><div><br></div><div>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.</div><div><br></div><div>For any LLDB devs who are interested in llvm::Error, the lightning talk that introduced it is at: <a href="https://www.youtube.com/watch?v=Wq8fNK98WGw" target="_blank">https://www.youtube.com/watch?v=Wq8fNK98WGw</a> , and the API is covered in more detail in the LLVM programmer's manual: <a href="http://llvm.org/docs/ProgrammersManual.html#recoverable-errors" target="_blank">http://llvm.org/docs/ProgrammersManual.html#recoverable-errors</a> .</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="m_-710329424808868927HOEnZb"><div class="m_-710329424808868927h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 28, 2017 at 8:40 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>For now though, I'm only proposing a very simple rename with minimal invasiveness.</div><div><br></div><div>Comments?</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div>