search for: exitcatch

Displaying 4 results from an estimated 4 matches for "exitcatch".

2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...ing around to it. It mirrors the EH pointer value required by Itanium EH. > > I'm not married to reusing 'resume', other candidate names include > 'unwind' and 'continue', and I'd like more ideas > > The first thing that comes to mind is 'endatch/exitcatch', but to use that > you'd need to rename other things since it would be confusing vis-à-vis > catchendblock and lack symmetry with catchblock that isn't prefixed with > begin/enter. > > You could consider 'filter' (or 'filterblock') for 'catchblock'...
2015 May 18
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
On Mon, May 18, 2015 at 12:03 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > Thanks for sending this out. We're looking forward to seeing this come > about, since we need funclet separation for LLILC as well (and I have > cycles to spend on it, if that would be helpful). > > > > Some questions about the new proposal: > > >
2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...t mirrors the EH pointer value > required by Itanium EH. > > > > > I'm not married to reusing 'resume', other candidate names include > 'unwind' and 'continue', and I'd like more ideas > > The first thing that comes to mind is 'endatch/exitcatch', but to use that > you'd need to rename other things since it would be confusing vis-à-vis > catchendblock and lack symmetry with catchblock that isn't prefixed with > begin/enter. > > You could consider 'filter' (or 'filterblock') for 'catchblock'...
2015 May 20
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
...t mirrors the EH pointer value > required by Itanium EH. > > > > > I'm not married to reusing 'resume', other candidate names include > 'unwind' and 'continue', and I'd like more ideas > > The first thing that comes to mind is 'endatch/exitcatch', but to use that > you'd need to rename other things since it would be confusing vis-à-vis > catchendblock and lack symmetry with catchblock that isn't prefixed with > begin/enter. > > You could consider 'filter' (or 'filterblock') for 'catchblock'...