aaron.ballman added a comment.
In D128249#3599551 <https://reviews.llvm.org/D128249#3599551>, @plotfi wrote:
> Thanks for the feedback on corner cases @aaron.ballman, this will give me
> more concrete things to think about here.
>
> At the moment I mainly thinking about a case:
>
> typedef int foo;
> enum : foo {} __attribute__((__clone_attrs_from__(foo)));
>
> This is mostly because of how NS_OPTIONS enums on Darwin are defined through
> a macro.
> We have been looking into breaking up how the typedef and the enum are
> defined for better behavior with C++.
> The only challenge is that if an NS_OPTIONS macro is used to declare an enum
> and an attribute is specified either before or after, it will then only apply
> to either the typedef or the enum.
>
> Thats the reason for a clone_attrs attribute.
Ah, thank you for the explanation. That is an interesting case. Another
potential idea to consider is the idea of "inheriting" attributes from a
related interface. e.g., a derived class which inherits attributes from the
base, or an enum with a fixed underlying type inheriting attributes from the
fixed type, etc. I've not given it a lot of thought, but it seems like there's
a relationship there that might make sense for attributes in general. As an
example:
struct [[gnu::packed]] S {
char c;
int i;
};
struct T {
char c;
int i;
};
template <typename U>
struct [[inherits_attributes]] V : U {
double d;
};
Where instantiating `V<S>` would result in both `V` and `S` being packed, but
instantiating `V<T>` would not pack either. (Again, I've not put a ton of
thought into it, but it's a possible alternative design worth considering.)
> I'll update description soon.
>
> In D128249#3598507 <https://reviews.llvm.org/D128249#3598507>, @aaron.ballman
> wrote:
>
>> Can you add some details to the patch summary as to what problem you're
>> trying to solve with these changes?
>>
>> The idea itself has some interesting edge cases to think about:
>>
>> [[some_attr]] void decl();
>> [[clone_attrs_from(decl)]] void other();
>> [[some_new_attr]] void decl();
>>
>> int main() {
>> other(); // Does other see some_new_attr as well?
>> }
>>
>> or
>>
>> [[hot]] void decl();
>> [[clone_attrs_from(decl), cold]] void other_decl(); // Do you properly
>> catch the mutual exclusions?
>>
>> or
>>
>> [[some_attr_requiring_the_func_return_a_pointer]] int *decl();
>> [[clone_attrs_from(decl)]] int other(); // Do you properly catch the
>> semantic restrictions?
>>
>> or
>>
>> struct [[some_struct_attr]] S { ... };
>> [[clone_attrs_from(S)]] void other(); // Do you properly catch the
>> semantic restrictions?
>>
>> or
>>
>> [[some_attr]] void decl();
>> [[clone_attrs_from(decl)]] void decl(); // Uh oh, recursive.
>>
>> (I'm sure there are more situations I'm missing, but you get the idea about
>> needing to be very careful with the edge cases.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128249/new/
https://reviews.llvm.org/D128249
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
