[PATCH] D17865: Add replacement = "xxx" to DeprecatedAttr.
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 9 11:45:55 PST 2016
aaron.ballman added a comment.
In http://reviews.llvm.org/D17865#370912, @manmanren wrote:
> Hi Aaron,
>
> Thanks for the review!
>
> > I like the idea of a potential fixit being provided by the attribute, but I do not agree with the way the feature is surfaced in this patch.
>
> >
>
> > For the GNU-style attribute, the named argument functionality is sufficiently novel syntax that I would strongly like to avoid it, especially since __attribute__((deprecated)) is supported by multiple compilers.
>
>
> I suggested `replacement = ""` mostly for its explicitness, especially when we already have an optional message argument "".
> If a user only want to specify replacement without a message, we can say deprecated(replacement = "xxx")
> With 'replacement =`, the user will need to specify an empty message.
I do like the explicit nature of this approach, but I'm worried about it being too novel. For instance, would this compel GCC to implement a similar parsing feature since they also support the deprecated attribute, that sort of thing. Also, it feels like a bit of an odd design in C and C++ since nothing else in the language supports argument passing by name like that (and I would really hate to see us use = blah only to find out that C++ someday standardizes on something different).
> But your concern makes sense too. We can support the following:
> deprecated("xxx") --> a message
> deprecated("xxx, "fixit") --> a message and a fixit
I think this is the correct approach, even with multiple optional arguments.
> > We should not be adding this functionality to the C++-style attribute in the gnu namespace; that's not our vendor namespace to modify.
>
>
> I believe the patch currently does not change the C++-style attribute. Of course, I should add testing cases to verify.
I believe the patch does change the C++-style attribute in the gnu namespace, as best I can tell. e.g., it would now allow: ``[[gnu::deprecated("something", "a fixit")]]``. We need to be careful not to allow this unless GCC allows the same syntax, otherwise we are hijacking their vendor attribute namespace with something incompatible.
> I wouldn't be opposed to adding a clang namespace where we support this feature, however.
>
> > We definitely need to make sure we are not modifying the functionality for the C++ standards-based attribute
>
>
> Is this ("the C++ standards-based attribute") the same as "the C++-style attribute" you mentioned above?
This is talking about the C++14 [[deprecated]] attribute. We want to make sure we don't allow [[deprecated("foo", "fixit")]], which I don't think your patch does (but we should have tests ensuring it).
> , or the __declspec based attribute (for pretty printing, as well as parsing, etc).
> Yes, I should add testing cases to make sure __declspec is not changed at all with this patch.
>
> > So this change is missing a lot of tests to make sure we do not support this feature in places where it doesn't belong.
>
http://reviews.llvm.org/D17865
More information about the cfe-commits
mailing list