Displaying 4 results from an estimated 4 matches for "onstacksize".
2013 Jul 23
2
[LLVMdev] [RFC] Add warning capabilities in LLVM.
...ers point (sorry, I hate to play
Telephone here - but hope to help clarify some positions... apologies
if this just further obfuscates/confuses). I believe the idea is some
kind of generic callback type with a bunch of no-op-default callbacks,
override the ones your frontend cares about ("void onStackSize(size_t
bytes)", etc...).
Yes, we could come up with a system that doesn't require adding a new
function call for every data that needs to be provided. Does it seem
likely we'll have so many of these that we'll really want/need that?
> I think we should still provide an informa...
2013 Jul 23
0
[LLVMdev] [RFC] Add warning capabilities in LLVM.
...hate to play
> Telephone here - but hope to help clarify some positions... apologies
> if this just further obfuscates/confuses). I believe the idea is some
> kind of generic callback type with a bunch of no-op-default callbacks,
> override the ones your frontend cares about ("void onStackSize(size_t
> bytes)", etc...).
I see.
>
> Yes, we could come up with a system that doesn't require adding a new
> function call for every data that needs to be provided. Does it seem
> likely we'll have so many of these that we'll really want/need that?
That’s a good...
2013 Jul 22
0
[LLVMdev] [RFC] Add warning capabilities in LLVM.
Hi,
Compared to my previous email, I have added Hal’s idea for formatting the message and pull back some idea from the "querying framework”.
Indeed, I propose to add some information in the reporting so that a front-end (more generally a client) can filter the diagnostics or take proper actions.
See the details hereafter.
On Jul 22, 2013, at 2:25 PM, Chandler Carruth <chandlerc at
2013 Jul 22
5
[LLVMdev] [RFC] Add warning capabilities in LLVM.
On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher <echristo at gmail.com>wrote:
> >> This is pretty much the same as what Quentin proposed (with the
> addition of the enum), isn't it?
> >>
> >
> > Pretty close yeah.
> >
>
> Another thought and alternate strategy for dealing with these sorts of
> things:
>
> A much more broad set of