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 so
>
> /// ...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 Ham
For instances where we know that we just want to log errors and continue
with some sensible default, we could introduce a new utility template along
the lines of:
template
T logUnwrap(Expected Result, T DefaultValue = T()) {
if (Result)
return std::move(*Result);
else {
log(Result.tak
Yeah - operations that may produce an valid result *and* a diagnostic would
be better suited to Status, or a pair where we want a hard
requirement that the API client check the diagnostic.
- Lang.
On Mon, May 1, 2017 at 5:27 PM, Jim Ingham wrote:
>
> > On May 1, 2017, at 4:52 PM, Zachary Turner
Hi Zachary,
... Then instead of Expected you could have WithDiagnostics that
> enforces the proper semantics.
You mean something like an ErrorAnd? Chris Bieneman floated that idea
for some libObject code but we haven't got around to implementing it. If it
were generically useful we could do some
Cool. This is just the rename portion, right?
Sorry I didn't respond to your last message too.
I suppose, but I'm not sure ErrorAnd captures the intended meaning very
> well. In any case, that's not super important at this stage since this
> isn't on the immediate horizon.
Do you just mean tha
Leaving 'Status' aside for now (the rename makes perfect sense), I'm basing
my ErrorAnd / WithError naming suggestion on this comment:
Is there any chance of introducing something like make_status() into
> llvm/Error.h, that constructs the llvm::Error in such a way that it still
> interoperates ni
Hi clang-dev, lldb-dev,
It looks like my clang commit r305850, which modified ASTImporter to import
method override tables from an external context, introduced a new bug which
manifests as incorrect vtable layouts for LLDB expression code.
The bug itself is fairly straightforward. In r305850 I in
gt; ```
> >
> > Thanks,
> > Gabor
> > On Fri, Aug 10, 2018 at 3:47 PM Alexey Sidorin
> wrote:
> > >
> > > (+ Gabor and Gabor)
> > >
> > > Hi Lang,
> > >
> > > We faced a very similar issue with record field
Hi Richard,
Perhaps a better approach would be to make the "minimal" mode for the
> ASTImporter provide an ExternalASTSource to lazily complete the AST as
> needed (thereby avoiding violating the invariant, because you would
> populate the lexical declarations list whenever anyone actually asks fo
Hi Gábor, Richard,
Hi Richard, maybe my understanding is not correct, but I believe the
> situation is somewhat twisted and reversed...
Is this relationship recursive? (Should it be?) I.e. When ClangASTSource
uses ASTImporter to minimally import a Decl, should that Decl have another
ExternalASTS
11 matches
Mail list logo
