[PATCH] Diagnose 'optnone' versus conflicting attrs on another decl

[Robinson, Paul]

If the compiler is doing something that isn't what the source says to do, the compiler should say so.  That's the principle behind this patch.

Even though the reason we ignore one attribute is because of a different attribute whose anticipated use-case is a temporary debugging measure, the principle should still apply.  Currently we're inconsistent, because we error if the attributes are on the same declaration but silently ignore one if they're on different declarations.  That inconsistency is another Bad Thing.
After this patch, we'd error on the same declaration and warn on different declarations, which is also inconsistent.  I was contemplating downgrading that error to a warning, so that the behavior is the same all around.
--paulr

From: Sean Silva [mailto:chisophugis at gmail.com]
Sent: Thursday, December 11, 2014 5:33 PM
To: Robinson, Paul
Cc: cfe-commits at cs.uiuc.edu; Aaron Ballman (aaron.ballman at gmail.com)
Subject: Re: [PATCH] Diagnose 'optnone' versus conflicting attrs on another decl

Sort of a bigger-picture question: does it make sense to warn about this? I thought that optnone was just for debugging; is there a use case where the user would put optnone on something when debugging and actually care about whether optnone is overriding something else?

-- Sean Silva

On Thu, Dec 11, 2014 at 4:27 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
Diagnose when attribute 'optnone' conflicts with attributes on a
different declaration.

I modeled this on how dllimport/dllexport are handled; specifically,
I made 'optnone' continue to "win" over 'always_inline' and 'minsize'.
This preserves the previous "winner" behavior but adds the diagnostics
that were requested.

I have two questions about all this.

First, the diagnostics point to the attribute being ignored, but not
to the attribute that caused it to be ignored.  Is that okay?  This
would be a problem for dllimport/dllexport as well as the new cases.

Second, now that there are 5 similar cases (dllimport v. dllexport,
plus optnone v. always_inline/minsize) it seems like there could be
an opportunity to refactor some of that diagnostic checking into a
templated helper function, along the lines of mergeVisibilityAttr.
Should I pursue that? (Not clear it's much of a win... but maybe.)

Thanks,
--paulr


_______________________________________________
cfe-commits mailing list
cfe-commits at cs.uiuc.edu<mailto:cfe-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141212/726d0508/attachment.html>