search for: errorkind

...ondered about the somewhat unusual use of error strings in LLVM (that you pass in a string, which can be assigned a descriptive error message). Better would be, IMHO, to provide an interface along the lines of this: > > class ErrorHandler > { > public: > virtual void Report(ErrorKind kind, 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 co...

...or strings in LLVM (that you pass in a string, which can > > be assigned a descriptive error message). Better would be, IMHO, > > to provide an interface along the lines of this: > > > > class ErrorHandler > > { > > public: > > virtual void Report(ErrorKind kind, 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,...

...have a number of times wondered about the somewhat unusual use of error strings in LLVM (that you pass in a string, which can be assigned a descriptive error message). Better would be, IMHO, to provide an interface along the lines of this: class ErrorHandler { public: virtual void Report(ErrorKind kind, 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. ErrorK...

...gt; > > be assigned a descriptive error message).  Better would be, IMHO, >> > > to provide an interface along the lines of this: >> > > >> > > class ErrorHandler >> > > { >> > > public: >> > >         virtual void Report(ErrorKind kind, 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 >> > &g...

...in a string, which can > > > be assigned a descriptive error message). Better would be, IMHO, > > > to provide an interface along the lines of this: > > > > > > class ErrorHandler > > > { > > > public: > > > virtual void Report(ErrorKind kind, 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 probab...

...scriptive error message). Better would be, IMHO, > >> > > to provide an interface along the lines of this: > >> > > > >> > > class ErrorHandler > >> > > { > >> > > public: > >> > > virtual void Report(ErrorKind kind, 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 ab...

....  Better would be, IMHO, >> >> > > to provide an interface along the lines of this: >> >> > > >> >> > > class ErrorHandler >> >> > > { >> >> > > public: >> >> > >         virtual void Report(ErrorKind kind, 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 w...

...uot;invalid_CFG, invalid_IndVar, invalid_IndEdge, ... ? In that case, I could provide a small patch file for this purpose -:) I think it would still be nice to get rid of this macro. We could probably have a default function that takes an enum to report different errors in the reportInvalid(enum errorKind) style. And then several others that would allow more complex formatting (e.g. reportInvalidAlias(AliasSet)). Especially the code after 'isMustAlias()' would be nice to move out of the main scop detection. However, this issue is not directly related to the speedup work, so you are welco...

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

...invalid_IndVar, invalid_IndEdge, ... ? In that case, I could provide a small patch file for this purpose -:) > >I think it would still be nice to get rid of this macro. We could >probably have a default function that takes an enum to report different >errors in the reportInvalid(enum errorKind) style. And then several >others that would allow more complex formatting (e.g. >reportInvalidAlias(AliasSet)). Especially the code after 'isMustAlias()' >would be nice to move out of the main scop detection. > >However, this issue is not directly related to the speedup wo...

At 2013-07-22 12:16:53,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/21/2013 07:33 PM, Star Tan wrote: >> At 2013-07-22 01:40:31,"Tobias Grosser" <tobias at grosser.es> wrote: >> >>> On 07/21/2013 09:49 AM, Star Tan wrote: >>>> Hi all, >>>> >>>> >>>> I have attached a patch file to

On 07/21/2013 07:33 PM, Star Tan wrote: > At 2013-07-22 01:40:31,"Tobias Grosser" <tobias at grosser.es> wrote: > >> On 07/21/2013 09:49 AM, Star Tan wrote: >>> Hi all, >>> >>> >>> I have attached a patch file to reduce the polly-detect overhead. >> >> Great. >> >>> My idea is to avoid calling TypeFinder in