plugin callbacks after compiler errors

plugin callbacks after compiler errors

[Taras Glek]

While developing my plugin I've noticed that many callbacks need to be 
guarded with "if (errorcount)" or the plugin will cause a gcc crash due 
to receiving less complete data than it expected.

Should the plugin API guard callbacks in invoke_plugin_callbacks() to 
avoid 99% of plugins running into this issue?

Taras

Re: plugin callbacks after compiler errors

[Basile STARYNKEVITCH]

Taras Glek wrote:
> While developing my plugin I've noticed that many callbacks need to be 
> guarded with "if (errorcount)" or the plugin will cause a gcc crash 
> due to receiving less complete data than it expected.
>
> Should the plugin API guard callbacks in invoke_plugin_callbacks() to 
> avoid 99% of plugins running into this issue? 


I am not sure this should be a fixed, wired (ie built-in) policy. One 
could imagine some plugins whose main role is precisely to issue 
additional errors (and IIRC, your TreeHydra did something similar to that).

Maybe we should just fix the documentation, saying that plugins should 
care (and plugin writers should think of) previously detected errors.

Maybe we might differentiate errors found by other passes and error 
found by plugins.

Maybe we should also extend the API so that some plugins get disabled 
when errorcount is >0. I tend to believe it should not become a general 
policy (but at least tunable plugin by plugin) but I may be wrong.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: plugin callbacks after compiler errors

[Diego Novillo]

On Tue, Jun 9, 2009 at 15:33, Taras Glek<taras.glek@gmail.com> wrote:
> While developing my plugin I've noticed that many callbacks need to be
> guarded with "if (errorcount)" or the plugin will cause a gcc crash due to
> receiving less complete data than it expected.

More details please.  What exactly is the error and how is errorcount related?

> Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid
> 99% of plugins running into this issue?

At the point that plugins are invoked, they should be able to deal
with whatever state the IL is at that moment.  I'd favor flexibility
over protection here.  But I'd like to see more details on what you're
after here.


Diego.

Re: plugin callbacks after compiler errors

[Taras Glek]

Diego Novillo wrote:
> On Tue, Jun 9, 2009 at 15:33, Taras Glek<taras.glek@gmail.com> wrote:
>   
>> While developing my plugin I've noticed that many callbacks need to be
>> guarded with "if (errorcount)" or the plugin will cause a gcc crash due to
>> receiving less complete data than it expected.
>>     
>
> More details please.  What exactly is the error and how is errorcount related?
>
>   
>> Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid
>> 99% of plugins running into this issue?
>>     
>
> At the point that plugins are invoked, they should be able to deal
> with whatever state the IL is at that moment.  I'd favor flexibility
> over protection here.  But I'd like to see more details on what you're
> after here.
>   
This is more of a polish issue than anything else. Trouble is that one 
may never see these bugs during plugin development unless the plugins 
are tested on files that have syntax errors.

    Test command: /home/bradh/devel/gcc-build/gcc/cc1 -quiet -O1
-ftest-coverage -fplugin=../gcc_dehydra.so -o /dev/null
-fplugin-arg-gcc_dehydra-=test_numinfo.js numinfo.cc
    Failure msg: Expected 'OK' output; Errors:
 numinfo.cc:14:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘boolvar’
numinfo.cc:19:7: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘enumvar’
numinfo.cc:21:7: error: expected identifier or ‘(’ before ‘&’ token
numinfo.cc:22:21: error: ‘enumvar’ undeclared here (not in a function)
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event            Plugins
PLUGIN_FINISH_TYPE    gcc_dehydra 
PLUGIN_FINISH_UNIT    gcc_dehydra 
PLUGIN_CXX_CP_PRE_GENERICIZE    gcc_dehydra 
PLUGIN_FINISH    gcc_dehydra 
PLUGIN_EVENT_LAST    gcc_dehydra 
plugin_init    gcc_dehydra 
numinfo.cc:22:1: internal compiler error: tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in process_type, at dehydra_plugin.c:139
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Stuff like FINISH_TYPE, PLUGIN_CXX_CP_PRE_GENERICIZE, etc can end up with error nodes instead of what is normally expected to be there.

I can't imagine a usecase for when it would be useful for a plugin to 
have the error marker node.

As I said, it's a minor polish issue. It may be sufficient to just have 
a note in the documentation as Basil suggested.


Taras

Re: plugin callbacks after compiler errors

[Rafael Espindola]

> As I said, it's a minor polish issue. It may be sufficient to just have a
> note in the documentation as Basil suggested.

I would prefer just changing the documentation too. In general I think
that plugins
should see gcc the same way a builtin pass does. If a plugin needs to
look at the
IL early in the pipeline it should be ready to work with previous errors.

>
> Taras
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: plugin callbacks after compiler errors

[Diego Novillo]

On Mon, Jun 15, 2009 at 09:32, Rafael Espindola<espindola@google.com> wrote:
>> As I said, it's a minor polish issue. It may be sufficient to just have a
>> note in the documentation as Basil suggested.
>
> I would prefer just changing the documentation too. In general I think
> that plugins
> should see gcc the same way a builtin pass does. If a plugin needs to
> look at the
> IL early in the pipeline it should be ready to work with previous errors.

Agreed.  As we chatted last week, we may want to offer a simplified
interface to those plugins that are never going to be integrated with
the compiler.  For now, plugins should get on the same roller coaster
the rest of the passes are in.

However, that may be more work than it's worth.  It would force an API
translation layer that may be burdensome to maintain.  I would prefer
to wait until we have more experience with plugin usage.


Diego.

Re: plugin callbacks after compiler errors

[Basile STARYNKEVITCH]

Rafael Espindola wrote:
>> As I said, it's a minor polish issue. It may be sufficient to just have a
>> note in the documentation as Basil suggested.

I am sorry to be picky, but my first name is spelled Basile (in France, 
where I live and am a citizen).
I do know that is it written Basil in English & Vasilii in 
(transliterated) Russian; but I prefer to be called by my official first 
name; unless it is an English or American habit to change the spelling 
of names.

Indeed my parents me after Basil of Caesarea, 
http://en.wikipedia.org/wiki/Basil_of_Caesarea (called Basil the Great 
in the Orthodox church; he is the author of several remarkable texts, 
and of the http://en.wikipedia.org/wiki/Basil_of_Caesarea).

But please do me a favor: on mailing lists spell my first name as it is 
in my signature. Actually, I would suppose that rule is nearly universal!

Of course, I don't care if russian speakers call me Vassilii or even Vassia.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***