search for: logallunhandlederrors

...iendly. It is easy to put a breakpoint at the diag handler. This proposal provides the same advantages. I noted the second point in the original RFC. The first is easily implemented using an idiom I've seen in llvm-objdump and elsewhere: void check(TypedError Err) { if (!Err) return; logAllUnhandledErrors(std::move(Err), errs(), "<tool name>"); exit(1); } ... TypedErrorOr<Result> R = doSomething(); check(R.takeError()); ... *R; Side-note: you can actually go one better and replace this idiom with: template <typename T> T check(TypedErrorOr<T> ValOrErr) { if (...

...wn to be out of date. I'm hoping to have that fixed by LLVM 11 but there is some feature work that I need to complete first. > > Can you share the specific errors that you're getting back? I would recommend replacing > > cantFail(callToFailingFunc(...)); > > with > > logAllUnhandledErrors(callToFailingFunc(...), errs(), "callToFailingFunc(...) failed:"); > Okay thank you - I will do that and report back. > On Mon, Apr 13, 2020 at 10:06 AM Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: >> >> Hi, >> >> I updated my project to LLVM...

...tended as a straw man. My point is that error recover is useful in general: there is a reason things like exceptions exist. Diagnostic handlers are very poorly suited to general error recovery. > > void check(TypedError Err) { > > if (!Err) > > return; > > > > logAllUnhandledErrors(std::move(Err), errs(), "<tool name>"); > > exit(1); > > } > That is not the same that you get with a diagnostic handler. What you > get is an exit after the error was propagated over the library layer, > instead of an exit at the point where the issue is fou...

Hi, I updated my project to LLVM 10.0 today and I am getting JIT symbol resolution errors. I could not find any example or updated tutorial or documentation that describes the new api - as all documentation seems out of date. I paste below some code snippets that show what I am doing: /* global syms is a array mapping names to function addresses */

Hi all, I am new to LLVM and have been working through the Kaleidoscope tutorial. Everything is working fine so far except for local externs (as opposed to things like the math functions, which are working). Note that I have seen this bug with the reference code listing, as well as my own code. link to code: https://llvm.org/docs/tutorial/LangImpl05.html#full-code-listing [c34n10 kaleidoscope]

We are trying to switch to the new orc v2 lljit engine at my work with hopes of parallel jitting. We are switching from the ExecutionEngine w/ OrcMCJitReplacement. We are having a hard time with global variables. We have found a way to create/emit new globals during jitting by using the old ExecutionEngine::getOrEmitGlobalVariable. Is there an easier way to do this with the new jit engine? We were

...ile at majumdar.org.uk> wrote: > Hi Lang, > > > > > Can you share the specific errors that you're getting back? I would > recommend replacing > > > > > > cantFail(callToFailingFunc(...)); > > > > > > with > > > > > > logAllUnhandledErrors(callToFailingFunc(...), errs(), > "callToFailingFunc(...) failed:"); > > > > > > > Okay thank you - I will do that and report back. > > > I had a look - to be honest I am not sure where the error is being > reported from. It looks like this: > > J...

Hi Mehdi, > If you subclass a diagnostic right now, isn’t the RTTI information available to the handler, which can then achieve the same dispatching / custom handling per type of diagnostic? > (I’m not advocating the diagnostic system, which I found less convenient to use than what you are proposing) I have to confess I haven't looked at the diagnostic classes closely. I'll take a