zygoloid wrote: > If the type is an extension, we can define its compatibility rules, can't we?
Well, the type `size_t` is not an extension, and we can't make strictly conforming C programs observably use a compatibility rule that the C standard doesn't permit. I think we *could* make the claim that there is no way in C to observe the difference between two types being compatible and being the same, and therefore this doesn't change the behavior of any strictly conforming code, so we can do it under as-if. Maybe that's true, but I don't think that's a good idea: if it's ever observable that these types are different but compatible, that would be a bug, and relying on nothing in C (or in C extensions that we don't own the specification of) exposing that ever seems risky. And I think the other arguments against still stand. (Note for example that this would presumably result in an ABI break for clang's `__attribute__((overloadable))`, and who knows how many other extensions that care about type identity not only type compatibility. Some of those are surely fixable, but are all of them?) > We certainly treat `_int32` and `int` as being compatible: > https://godbolt.org/z/66eKrWKcs It looks to me like we treat the keyword `_int32` as [just a funny spelling for `int`](https://godbolt.org/z/bWTh7PrcW) (and [don't even preserve the spelling as type sugar](https://godbolt.org/z/Wqs6Eaz77)), not as a distinct type that is merely compatible with `int`. https://github.com/llvm/llvm-project/pull/136542 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
