public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
       [not found]       ` <4E6F1B1C.9090404@st.com>
@ 2011-09-14  8:39         ` Romain Geissler
  2011-09-22 13:40           ` Dodji Seketeli
  0 siblings, 1 reply; 4+ messages in thread
From: Romain Geissler @ 2011-09-14  8:39 UTC (permalink / raw)
  To: Dodji Seketeli; +Cc: gcc-patches, Jason Merrill, gcc

Hi,

I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.

The followings does not currently trigger the PLUGIN_FINISH_DECL
(or not in all cases), but should them ?
 - function parameters (in the function prototype)
 - definition (with a function body) of a top-level function (while the exact
   same function definition enclosed in a class definition will trigger
   PLUGIN_FINISH_DECL)
 - label declaration
 - constants defined by enums
 - namespace

Romain.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
  2011-09-14  8:39         ` [PLUGIN] Fix PLUGIN_FINISH_TYPE Romain Geissler
@ 2011-09-22 13:40           ` Dodji Seketeli
  2011-09-22 14:18             ` Diego Novillo
  0 siblings, 1 reply; 4+ messages in thread
From: Dodji Seketeli @ 2011-09-22 13:40 UTC (permalink / raw)
  To: Romain Geissler; +Cc: gcc-patches, Jason Merrill, gcc, Diego Novillo

Romain Geissler <romain.geissler@gmail.com> a écrit:

> I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
>
> The followings does not currently trigger the PLUGIN_FINISH_DECL
> (or not in all cases), but should them ?
>  - function parameters (in the function prototype)
>  - definition (with a function body) of a top-level function (while the exact
>    same function definition enclosed in a class definition will trigger
>    PLUGIN_FINISH_DECL)
>  - label declaration
>  - constants defined by enums
>  - namespace

Indeed.  finish_decl is not called in those cases.  As to if the
PLUGIN_FINISH_DECL event should be emitted for those, I'd say yes, at
least if I believe what the description in plugin.def says:

    /* After finishing parsing a declaration. */
    DEFEVENT (PLUGIN_FINISH_DECL)

But I'd rather ask what the maintainers think about it.

Jason, Diego?

-- 
		Dodji

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
  2011-09-22 13:40           ` Dodji Seketeli
@ 2011-09-22 14:18             ` Diego Novillo
  2011-09-22 14:29               ` Romain Geissler
  0 siblings, 1 reply; 4+ messages in thread
From: Diego Novillo @ 2011-09-22 14:18 UTC (permalink / raw)
  To: Dodji Seketeli; +Cc: Romain Geissler, gcc-patches, Jason Merrill, gcc

On 11-09-22 09:40 , Dodji Seketeli wrote:
> Romain Geissler<romain.geissler@gmail.com>  a écrit:
>
>> I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
>>
>> The followings does not currently trigger the PLUGIN_FINISH_DECL
>> (or not in all cases), but should them ?
>>   - function parameters (in the function prototype)
>>   - definition (with a function body) of a top-level function (while the exact
>>     same function definition enclosed in a class definition will trigger
>>     PLUGIN_FINISH_DECL)
>>   - label declaration
>>   - constants defined by enums
>>   - namespace
>
> Indeed.  finish_decl is not called in those cases.  As to if the
> PLUGIN_FINISH_DECL event should be emitted for those, I'd say yes, at
> least if I believe what the description in plugin.def says:
>
>      /* After finishing parsing a declaration. */
>      DEFEVENT (PLUGIN_FINISH_DECL)
>
> But I'd rather ask what the maintainers think about it.
>
> Jason, Diego?

Yes, those events should trigger a PLUGIN_FINISH_DECL call.


Diego.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
  2011-09-22 14:18             ` Diego Novillo
@ 2011-09-22 14:29               ` Romain Geissler
  0 siblings, 0 replies; 4+ messages in thread
From: Romain Geissler @ 2011-09-22 14:29 UTC (permalink / raw)
  To: Diego Novillo; +Cc: Dodji Seketeli, gcc-patches, Jason Merrill, gcc


Le 22 sept. 2011 à 16:18, Diego Novillo a écrit :

> On 11-09-22 09:40 , Dodji Seketeli wrote:
>> Romain Geissler<romain.geissler@gmail.com>  a écrit:
>> 
>>> I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
>>> 
>>> The followings does not currently trigger the PLUGIN_FINISH_DECL
>>> (or not in all cases), but should them ?
>>>  - function parameters (in the function prototype)
>>>  - definition (with a function body) of a top-level function (while the exact
>>>    same function definition enclosed in a class definition will trigger
>>>    PLUGIN_FINISH_DECL)
>>>  - label declaration
>>>  - constants defined by enums
>>>  - namespace
>> 
>> Indeed.  finish_decl is not called in those cases.  As to if the
>> PLUGIN_FINISH_DECL event should be emitted for those, I'd say yes, at
>> least if I believe what the description in plugin.def says:
>> 
>>     /* After finishing parsing a declaration. */
>>     DEFEVENT (PLUGIN_FINISH_DECL)
>> 
>> But I'd rather ask what the maintainers think about it.
>> 
>> Jason, Diego?
> 
> Yes, those events should trigger a PLUGIN_FINISH_DECL call.

Ok, i've already implemented it in the C front-end. I'll post the whole patch soon.

Romain

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-09-22 14:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <4E6DBC5F.6070408@st.com>
     [not found] ` <m3littkdz4.fsf@seketeli.org>
     [not found]   ` <CAF+LTefkNpP-g0_30w75OxoatD3GWa+Os+VsBFkg0gN4R-=+xQ@mail.gmail.com>
     [not found]     ` <m3hb4hka5u.fsf@seketeli.org>
     [not found]       ` <4E6F1B1C.9090404@st.com>
2011-09-14  8:39         ` [PLUGIN] Fix PLUGIN_FINISH_TYPE Romain Geissler
2011-09-22 13:40           ` Dodji Seketeli
2011-09-22 14:18             ` Diego Novillo
2011-09-22 14:29               ` Romain Geissler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).