On Wed, Nov 4, 2015, at 10:34 AM, Krzysztof Kosiński wrote:
I’m also not sure if globally suppressing this kind of warning is recommended. I have not seen this kind of warning other than this, and I couldn’t even find its definition on the official Clang documentation. If this is not recommended, does anyone know how I can specifically suppress this particular warning?
Attributes are often compiler-specific, so specifying -Wno-unknown-attributes globally may be a reasonable idea. Is anyone against this?
Yes, I think this would be too broad, at least as a general principal.
If we disable *all* unknown attributes then we might be missing some that are important. Trying to limit is best. If it's like some other warnings one example had a 2% non-trivial rate. That is, only 2% of the occurrences took anything other than trivial fixes to get rid of. However... that remaining number were important. For unused parameters that 2% counted when you have hundreds of instances (6 out of 300, IIRC). And specifically we were able to spot low-level primitives (might have been in libgeom) that were being given X and Y, but then storing X twice and dropping Y.
So... at the very least we would want to be sure to only set that flag if the current compiler was a problem (e.g. is clang and also is a known picky version). Next, I'd like to see if we could limit the number of files the flag were added to.
However... in this case better than hoping the libgc maintainers fix things would be instead to just finish dropping it altogether. It did not end up solving key problems, as developers still need to follow special use-case rules in order to not leak things (which we aren't and thus do leak). Gtk+/Gtkmm have their own rules that address memory ownership so we need to just follow one set of rules instead of two.