search for: typederroror

Hi Michael, Rafael, Pawel, Apologies for the delayed reply - I was out on vacation last week. > In fact I would actually support outright > replacing ErrorOr with this if it can be done safely, as I find the > name TypedErrorOr a bit long. I find the name awkward too. I'll leave these classes as TypedError and TypedErrorOr<T> when I submit the initial patch to llvm-commits, but please feel free to comment on the names in that review. If the proposal is adopted I think the eventual plan should be to move to '...

...I like this idea in general. It's a better implementation of what > ErrorOr originally was before we removed the custom error support > because it wasn't used. In fact I would actually support outright > replacing ErrorOr with this if it can be done safely, as I find the > name TypedErrorOr a bit long. The main differences are * This will hopefully be used. * TypedErrorOr is really a TypedError or T. The situation before was not that ErrorOr was std::error_code or T. Since we are adding it, I would also support replacing every use of ErrorOr with TypedErrorOr and renaming it. Chee...

...antages. 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 (!ValOrErr) { logAllUnhandledErrors(ValOrErr.takeError(), errs(), "<tool nam...

...up a set of unit-tests for the TypedError system, and a new section of the LLVM Programmer's Manual describing its use. (2) Re-submit the original prototype (with minor tweaks) plus the unit-tests and programmers manual additions to llvm-commits fro review. (3) Begin threading TypedError and TypedErrorOr through MachOObjectFile in libObject, using ECError as a bridge between TypedError/TypedErrorOr and std::error_code/ErrorOr. The act of threading this through libObject will hit LLD, MCJIT and ORC, DebugInfo, LTO, ProfilingData and a host of command-line utilities. However, the ECError glue is fai...

Hi Rafael, > What prevents you from using a diag handler in the jit server that > sends errors/warnings over the RPCChannel? What would you do with errors that can't reasonable be serialized when they reach the diagnostic handler? And what would you do with the serialized bytes on the client end? - Lang. Sent from my iPhone On Feb 10, 2016, at 10:31 AM, Rafael Espíndola

...r, > instead of an exit at the point where the issue is found. > > We use the above code now because lib/Object has no diagnostic handler. > > > Side-note: you can actually go one better and replace this idiom with: > > > > template <typename T> > > T check(TypedErrorOr<T> ValOrErr) { > > if (!ValOrErr) { > > logAllUnhandledErrors(ValOrErr.takeError(), errs(), "<tool name>"); > > exit(1); > > } > > return std::move(*ValOrErr); > > } > > Yes, we do pretty much that in ELF/COFF lld. > &...

Hi All, I've been thinking lately about how to improve LLVM's error model and error reporting. A lack of good error reporting in Orc and MCJIT has forced me to spend a lot of time investigating hard-to-debug errors that could easily have been identified if we provided richer error information to the client, rather than just aborting. Kevin Enderby has made similar observations about the

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