This is now done in r302872, btw. I'm only able to test on Windows here,
but I didn't see any regressions (not sure why there would be), and there
were very few compilation failuers to fix up. So hopefully other platforms
don't run into any problems
On Wed, May 10, 2017 at 9:02 PM Zachary Turner
On Wed, May 10, 2017 at 8:33 PM Lang Hames wrote:
> 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 th
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
> On May 10, 2017, at 6:28 PM, Zachary Turner wrote:
>
> Yes, this is just the rename.
>
> Regarding the naming, if you call it ErrorAnd, or WithError, or anything that
> includes the word error, you are implying that something actually went wrong.
> I don't think that's the intended use cas
Yes, this is just the rename.
Regarding the naming, if you call it ErrorAnd, or WithError, or anything
that includes the word error, you are implying that something actually went
wrong. I don't think that's the intended use case, or at least not what I
have in mind (and from previous conversation
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
I'm probably going to be looking at submitting this this week, more likely
sooner rather than later. If I can get it all working hopefully even
tomorrow.
On Mon, May 1, 2017 at 5:49 PM Zachary Turner wrote:
> I suppose, but I'm not sure ErrorAnd captures the intended meaning very
> well. In an
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.
On Mon, May 1, 2017 at 5:43 PM Lang Hames wrote:
> Hi Zachary,
>
> ... Then instead of Expected you could have WithDiagn
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
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 nicely with everything else? Then instead of Expected you
could have WithDiagnostics that enforces the proper semantics.
On Mon, May 1, 2017
On Mon, May 1, 2017 at 5:27 PM Jim Ingham wrote:
>
> > On May 1, 2017, at 4:52 PM, Zachary Turner wrote:
> >
> > Yea, grouping the error and the result together is one of the most
> compelling features of it. It's called Expected, so where we would
> currently write something like:
> >
> > int
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
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
> On May 1, 2017, at 4:52 PM, Zachary Turner wrote:
>
> Yea, grouping the error and the result together is one of the most compelling
> features of it. It's called Expected, so where we would currently write
> something like:
>
> int getNumberOfSymbols(Error &Err) {}
>
> or
>
> Error getNu
Yea, grouping the error and the result together is one of the most
compelling features of it. It's called Expected, so where we would
currently write something like:
int getNumberOfSymbols(Error &Err) {}
or
Error getNumberOfSymbols(int &Count) {}
You would now write:
Expected getNumberOfSymbo
> On May 1, 2017, at 3:29 PM, Zachary Turner wrote:
>
> I'm confused. By having the library assert, you are informed of places where
> you didn't do a good job of backing from errors, thereby allowing you to do a
> *better* job.
>
> You said this earlier:
>
> > But a larger point about asse
I'm confused. By having the library assert, you are informed of places
where you didn't do a good job of backing from errors, thereby allowing you
to do a *better* job.
You said this earlier:
> But a larger point about asserting as a result of errors is that it makes
it seem to the lldb develope
> On May 1, 2017, at 3:12 PM, Zachary Turner wrote:
>
> Does Xcode ship with a build of LLDB that has asserts enabled? Because if
> not it shouldn't affect anything. If so, can you shed some light on why?
Not sure that's entirely relevant. The point is not to make failure points
assert the
Does Xcode ship with a build of LLDB that has asserts enabled? Because if
not it shouldn't affect anything. If so, can you shed some light on why?
On Mon, May 1, 2017 at 3:08 PM Jim Ingham wrote:
>
> > On May 1, 2017, at 2:51 PM, Zachary Turner wrote:
> >
> > I think we agree about the SB lay
> On May 1, 2017, at 2:51 PM, Zachary Turner wrote:
>
> I think we agree about the SB layer. You can't have mandatory checking on
> things that go through the SB API. I think we could code around that though.
>
> Regarding the other point, I actually think force checked errors *help* you
>
I think we agree about the SB layer. You can't have mandatory checking on
things that go through the SB API. I think we could code around that
though.
Regarding the other point, I actually think force checked errors *help* you
think about how to back out and leave the debug session alive.
Specif
> On May 1, 2017, at 12:54 PM, Zachary Turner wrote:
>
> The rename is just to avoid the spelling collision. Nothing in particular
> leads me to believe that unchecked errors are a source of major bugs.
>
> That said, I have some short term plans to begin making use of some llvm
> library cl
On 1 May 2017 at 19:48, Zachary Turner via lldb-dev
wrote:
>
>
> On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote:
>> If it is actually causing confusion (I haven't experienced such yet) I
>> don't mind typing some extra letters.
>
> I think that's in part because llvm::Error isn't very prevalent
The rename is just to avoid the spelling collision. Nothing in particular
leads me to believe that unchecked errors are a source of major bugs.
That said, I have some short term plans to begin making use of some llvm
library classes which deal in llvm::Error, and doing this first should make
thos
BTW, I'm interested to know if you have some analysis which leads you to think
that propagating unchecked errors actually is a big problem in lldb, or are you
just doing this to remove a spelling collision? I see a lot of bugs for lldb
come by, but I really haven't seen many that this sort of f
> On May 1, 2017, at 11:48 AM, Zachary Turner wrote:
>
>
>
> On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote:
> I'm mostly but not entirely tongue in cheek wondering why we aren't calling
> llvm::Error llvm::LLVMError, as the lldb error class much preceded it, but
> that's a minor point.
>
On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote:
> I'm mostly but not entirely tongue in cheek wondering why we aren't
> calling llvm::Error llvm::LLVMError, as the lldb error class much preceded
> it, but that's a minor point.
>
FWIW I think the naming chosen by LLVM is correct. It's intended
I'm mostly but not entirely tongue in cheek wondering why we aren't calling
llvm::Error llvm::LLVMError, as the lldb error class much preceded it, but
that's a minor point.
If it is actually causing confusion (I haven't experienced such yet) I don't
mind typing some extra letters.
As we've d
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 a
>
> /// ...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
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
31 matches
Mail list logo
