search for: errorkind_fatal

...t 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. You're right, this would be better. We have even already have it :) llvm/Support/ErrorHandling.h -Chris

...char *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 :) &g...

...uint code, const 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/...

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

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

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

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

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