search for: errorkind_error

...osition, const unichar *text, ...) = 0; > }; > > And then let the client, i.e. the frontend, derive from it and handle all the output in whichever way it wants to. The above example is probably too complex for LLVM, but that's what I use in my compiler. ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc. Position is simply a filename, a line number, and a character position. unichar is either char or wchar_t, depending on the build mode and target environment. You're right, this would be better. We have even already have it :) llvm/Support/ErrorHandling.h -Chris

...= 0; }; > > > > And then let the client, i.e. the frontend, derive from it and > > handle all the output in whichever way it wants to. The above > > example is probably too complex for LLVM, but that's what I use in > > my compiler. ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc. > > Position is simply a filename, a line number, and a character > > position. unichar is either char or wchar_t, depending on the > > build mode and target environment. > > You're right, this would be better. We have even already have it :) > > llvm/S...

...Position &position, const unichar *text, ...) = 0; }; And then let the client, i.e. the frontend, derive from it and handle all the output in whichever way it wants to. The above example is probably too complex for LLVM, but that's what I use in my compiler. ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc. Position is simply a filename, a line number, and a character position. unichar is either char or wchar_t, depending on the build mode and target environment. I hook it up so that I can buffer all errors encountered for later user. Cheers, Mikael -- Love Thy Frog! 2012/6/2 Justin Holewi...

...; And then let the client, i.e. the frontend, derive from it and >> > > handle all the output in whichever way it wants to.  The above >> > > example is probably too complex for LLVM, but that's what I use in >> > > my compiler.  ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc. >> > > Position is simply a filename, a line number, and a character >> > > position.  unichar is either char or wchar_t, depending on the >> > > build mode and target environment. >> > >> > You're right, this would be better.  We have...

...gt; > > And then let the client, i.e. the frontend, derive from it and > > > handle all the output in whichever way it wants to. The above > > > example is probably too complex for LLVM, but that's what I use in > > > my compiler. ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc. > > > Position is simply a filename, a line number, and a character > > > position. unichar is either char or wchar_t, depending on the > > > build mode and target environment. > > > > You're right, this would be better. We have even already have i...

...the client, i.e. the frontend, derive from it and > >> > > handle all the output in whichever way it wants to. The above > >> > > example is probably too complex for LLVM, but that's what I use in > >> > > my compiler. ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc. > >> > > Position is simply a filename, a line number, and a character > >> > > position. unichar is either char or wchar_t, depending on the > >> > > build mode and target environment. > >> > > >> > You're right, this...

...i.e. the frontend, derive from it and >> >> > > handle all the output in whichever way it wants to.  The above >> >> > > example is probably too complex for LLVM, but that's what I use in >> >> > > my compiler.  ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc. >> >> > > Position is simply a filename, a line number, and a character >> >> > > position.  unichar is either char or wchar_t, depending on the >> >> > > build mode and target environment. >> >> > >> >> > You...

On Sat, Jun 2, 2012 at 8:56 AM, Chris Lattner <clattner at apple.com> wrote: > On Jun 1, 2012, at 11:13 PM, Justin Holewinski wrote: > > In a way, they are. What if I want a debug trace in a multi-threaded >> context? Right now, all threads would just spew to the same stream and the >> result would be unreadable. If you allow threads to setup their own outs()

On Jun 1, 2012, at 11:13 PM, Justin Holewinski wrote: >> In a way, they are. What if I want a debug trace in a multi-threaded context? Right now, all threads would just spew to the same stream and the result would be unreadable. If you allow threads to setup their own outs() and errs() streams (transparently to the rest of LLVM), you can intercept these as you see fit, perhaps dumping