similar to: [RFC] Error handling in LLVM libraries.

Hi Mehdi, > I’m not sure to understand this claim? You are supposed to be able to extend and subclass the type of diagnostics? (I remember doing it for an out-of-tree LLVM-based project). You can subclass diagnostics, but subclassing (on its own) only lets you change the behaviour of the diagnostic/error itself. What we need, and what this patch supplies, is a way to choose a particular

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

Hi Mehdi, > For a generic error class it is not an option indeed, but I was looking at it in the context of LLVM internal use, so just like our RTTI is not an option for “generic RTTI” but fits our need, we could (not should) do the same with ErrorHandling. Definitely. If this was LLVM only there'd be a strong case for using the existing RTTI system. The reason for the new RTTI system is

Hi Mehdi, > Side question on the related work because I’m curious: did you look for similar generic scheme for error handling offered by other C++ libraries? Maybe the common scheme is to use C++ exceptions but since many folks disable them (hello Google ;-) ) there has been probably many other attempts to address this. I did look around, but not very hard. Among the people I asked, everyone

Hi James, > It seems to me that "[[clang::warn_unused_result]] class TypedError" is probably sufficient for ensuring people check a status return value; I'm not sure runtime checking really brings much additional value there. I see the attribute as complimentary. The runtime check provides a stronger guarantee: the error cannot be dropped on any path, rather than just "the

Hi Rafael, > The main thing I like about the diagnostic system is that it lets us > differentiate two related but independent concepts: > > * Giving the human using the program diagnostics about what went wrong. > * Propagating an error to the caller so that the upper library layer > can handle it or pass it up the stack. I don't think these are really independent. Whether

> > I don't think these are really independent. Whether or not you need to emit > > a diagnostic depends on whether a caller can handle the corresponding error, > > which isn't something you know at the point where the error is raised. > But you do in the diag handler. For example, if you are trying to open > multiple files, some of which are bitcode, you know to

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

Hi All, Now that this thread has accumulated some feedback, I thought I'd try to summarize my thoughts on error handling in LLVM, and why I think this proposal is worth adopting: (1) Failure to check an error *is* a programmatic error, and our error system should reflect this. This makes it easy to spot mistakes in our error handling and correct them. (2) Error returns should describe all

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,

> 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. *

Hi Rafael, > But they are always created, even if it as error the caller wants to > ignore. For example, you will always create a "file foo.o in bar.a is > not a bitcode" message (or copy sufficient information for that to be > created). With a dignostic handler no copying is needed, since the > call happens in the context where the error is found. It is easy to > see

On Wed, Feb 10, 2016 at 6:47 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > >> This highlights why I think it is important to keep diagnostics and > >> errors separate. In the solution you have there is a need to allocate > >> a std::string, even if that is never used. > > > > Errors are only constructed on the error path. There is no

----- Original Message ----- > From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Yaron Keren" <yaron.keren at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com> > Sent: Tuesday, January 26, 2016 9:39:34 AM > Subject: Re: [llvm-dev] lld:

The context issue may be solved by making all functions and context data members of a class. Sort of having the convenience of global variables accessible from all linker functions but without the regular global variable problems of initializing and re-entry. so the class is suitable aspart of a library. Most clang and LLVM classes works this way, not passing contexts around. 2016-01-22 6:25

This is a proposed patch to enhance FileSystem.h to add functionality (getting and setting permission bits and mapping an unmapping files). This implementation follows the N3365 proposal regarding permission bits. This functionality is needed for my next patch which will implement llvm/include/Support/FileOutputBuffer.h which is needed by lld. -------------- next part -------------- A

On Fri, May 18, 2012 at 3:07 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> +  error_code ec = sys::fs::status(filePathTwine, stat); > > stat is undefined if ec isn't success. ec will be success even in the case of > file_not_found. Actually I was wrong. The Windows and UNIX implementation disagree on this point. I'm going to change it to match

I now have an implementation of FileOutputBuffer (OutputBuffer was already taken). The patch supports the functionality listed below and I've tested that it works for lld. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileOutputBuffer.patch Type: application/octet-stream Size: 25308 bytes Desc: not available URL:

In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing object ownership. The Reader class currently has an interface that can be simplified down to: virtual error_code

On Jun 16, 2012, at 3:51 PM, Chris Lattner wrote: > On Jun 15, 2012, at 3:48 PM, Nick Kledzik wrote: > >> In lld we have a Reader class which is a factory that takes .o file(s) and produces an in memory lld::File object(s). But in doing so, there could be I/O errors (file not readable) or file may be malformed. We are also using C++11 in lld, so we use std::unique_ptr for managing