AaronBallman wrote:
> However, we do have some prior art -- we're not inventing the whole idea of
> decl-merging from scratch right now. So maybe we can follow that prior art?
> For example, top-level attributes on a struct's definition can be inherited
> from a declaration in the same scope. It seems plausible that the same would
> be true for redefinition, and then maybe we'd also extend that same
> declaration-attribute-merging to fields within the struct.
Well, yes and no. We have prior art of doing this when we are checking valid
redeclaration, but this is also about type merging as much as declaration
merging. And with redefinitions, you run into problems you wouldn't be able to
run into with redeclarations. e.g.,
```
struct S {
char c;
int x;
};
void func(struct S s) { ... } // Expects an unpacked structure
struct S {
[[gnu::packed]] char c;
[[gnu::packed]] int x;
};
int main() {
struct S s = {};
func(s); // Passes a packed structure
}
```
You couldn't run into this situation with redeclarations because you previously
could not redeclare the structure fields.
The logic would sort of work out for standard attributes, at least by
happenstance. There could be observable differences with `[[reproducible]]` and
`[[unsequenced]]` but those are much more contrived situations given the nature
of the attributes.
> So...yeah...
Yeah, there's a fair amount of moving parts. This is why I want to go with the
most conservative approach of rejecting unless the attributes are the same. At
some point, we'll get around to being able to tablegen more of this logic
(likely leaning on the existing tablegen for some things like inheritable
declaration attributes, and introducing new concepts like inheritable type
attributes) and we can then relax the restrictions. But if we release in an
unrestricted form, users *will* begin to rely on invalid code being accepted
and we'll be in a pickle.
Curiously, GCC doesn't merge the standard attributes either, it seems to do
last-one-wins: https://godbolt.org/z/j3W7ej5Kq
https://github.com/llvm/llvm-project/pull/132939
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
