void foo(void) __attribute__((user("bleh")));
GCC will complain
foo.cc:1: warning: 'user' attribute directive ignored
whenever dehydra is not loaded. Since our build system uses -Werror
for every build, users are not really able to use this attribute in
their dehydra scripts. Has anyone run into this? I have suggested
guarding the attribute with a special macro and define that macro
every time they use dehydra, but that's awkward.
We could change the compiler to never complain about the 'user'
attribute, unless plugins are loaded,but that also seems incomplete.
Compiling with -Wno-attributes helps, but that turns off all
attributes. Perhaps we could control warnings on the 'user' attribute
with a new -Wuser-attribute?
Thanks. Diego.
> void foo(void) __attribute__((user("bleh")));
>
> GCC will complain
>
> foo.cc:1: warning: 'user' attribute directive ignored
>
> whenever dehydra is not loaded. Since our build system uses -Werror
> for every build, users are not really able to use this attribute in
> their dehydra scripts. Has anyone run into this? I have suggested
> guarding the attribute with a special macro and define that macro
> every time they use dehydra, but that's awkward.
That's what mozilla does. We have a --with-static-checking configure flag,
and our annotations (NS_FINAL_CLASS etc) are defined conditionally. We have
to do that anyway since we compile with MSVC and SunCC and other compilers.
You could use -Wno-attributes, which suppresses warnings about *all* unknown
attributes. Alternately, we could modify GCC so that -Wno-attributes takes
an optional argument, e.g.
-Wno-attributes=user
-Wno-attributes=NS_stack
--BDS
> I am surprised & delighted that Diego mentions Dehydra. I thought it was
> Taras Glek's plugin, so Mozilla (not Google) related.
Dehydra still is developed by Mozilla. We are just starting to use it
internally to implement some analyses.
> I have a simpler suggestion:
>
> every attribute whose name starts with an underscore like "_user" or
> "_foogreen" or "_BORING" never produce any warnings, except perhaps in the
> plugin handling it.
Yeah. Or perhaps a variant of this. Allow -Wno-attribute to take as
argument the name of the attribute you want to ignore.
> PS if the dev-stati...@lists.mozilla.org list is low volume, I would
> like to subscribe if possible.
I subscribed following some link from Dehydra's main page
(https://developer.mozilla.org/en/Dehydra)
Diego.
> That's what mozilla does. We have a --with-static-checking configure flag,
> and our annotations (NS_FINAL_CLASS etc) are defined conditionally. We have
> to do that anyway since we compile with MSVC and SunCC and other compilers.
OK.
> You could use -Wno-attributes, which suppresses warnings about *all* unknown
> attributes. Alternately, we could modify GCC so that -Wno-attributes takes
> an optional argument, e.g.
>
> -Wno-attributes=user
> -Wno-attributes=NS_stack
Good idea. I'll see about implementing this.
Thanks. Diego.
On Fri, Oct 16, 2009 at 09:12, Benjamin Smedberg <benj...@smedbergs.us> wrote:
> On 10/16/09 8:17 AM, Diego Novillo wrote:
>
>> void foo(void) __attribute__((user("bleh")));
>>
>> GCC will complain
>>
>> foo.cc:1: warning: 'user' attribute directive ignored
>>
>> whenever dehydra is not loaded. Since our build system uses -Werror
>> for every build, users are not really able to use this attribute in
>> their dehydra scripts. Has anyone run into this? I have suggested
>> guarding the attribute with a special macro and define that macro
>> every time they use dehydra, but that's awkward.
>
> That's what mozilla does. We have a --with-static-checking configure flag,
> and our annotations (NS_FINAL_CLASS etc) are defined conditionally. We have
> to do that anyway since we compile with MSVC and SunCC and other compilers.
OK.
> You could use -Wno-attributes, which suppresses warnings about *all* unknown
> attributes. Alternately, we could modify GCC so that -Wno-attributes takes
> an optional argument, e.g.
>
> -Wno-attributes=user
> -Wno-attributes=NS_stack
Good idea. I'll see about implementing this.
Thanks. Diego.
Diego> void foo(void) __attribute__((user("bleh")));
Diego> foo.cc:1: warning: 'user' attribute directive ignored
Diego> We could change the compiler to never complain about the 'user'
Diego> attribute, unless plugins are loaded,but that also seems incomplete.
How about just having __attribute__ ((plugin (pluginname, arg...)))
and ignoring an attribute when the named plugin is not loaded?
It seems to me that having a single "user" attribute shared by all
plugins will lead to some pain later on.
Tom
Dehydra is going to switch from the generic user attribute to specific
GCC-registered attributes __attribute__((NS_final)) at some point when one
of us can code it up. In particular it would be nice to have more validation
of attribute application: in particular because the user attribute can apply
to types or declarations it's much easier for code authors to misplace,
especially when combined with function pointers.
I don't particularly like __attribute__((plugin (pluginname, arg))). You're
forced to code plugin names into your source, when you may not actually know
the name of the plugin that's going to process your annotations. Mozilla is
likely to have generic attributes (NS_final and others) which are not
specific to one plugin. We already have a volunteer working on an
optimization pass and an analysis pass for an attribute always_returns_zero:
these passes are likely to be in different plugins (optimization in a
compiled plugin, analysis in dehydra/treehydra).
--BDS
I doubt you are using raw attributes in your code. They are likely
hidden behind macros. At Mozilla we support a custom static analysis
build configuration. Perhaps the correct solution would be for the
plugin to define a new preprocessor variable, ie something akin to
-DDEHYDRA.
Though I'm not sure how that would be a benefit over specifying
-DDEHYDRA on the gcc commandline.
Taras
> Given
>
> void foo(void) __attribute__((user("bleh")));
>
> GCC will complain
>
> foo.cc:1: warning: 'user' attribute directive ignored
> We could change the compiler to never complain about the 'user'
> attribute, unless plugins are loaded,but that also seems incomplete.
I undestand why someone might want that warning, but must it be
enabled by -Wall?
Adding -Wunused-attributes to CFLAGS won't be such a burden to
projects using an advanced feature such as GCC plugins.
--
P.