[PATCH] D125919: Drop qualifiers from return types in C (DR423)

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D125919#3570145 <https://reviews.llvm.org/D125919#3570145>, @rjmccall wrote:

> In D125919#3569928 <https://reviews.llvm.org/D125919#3569928>, @aaron.ballman wrote:
>
>> In D125919#3560523 <https://reviews.llvm.org/D125919#3560523>, @aaron.ballman wrote:
>>
>>> All that said, I think you can see why I'm hoping to get an answer from WG14 as to what to do. Reasonable folks are disagreeing on what the standard requires here.
>>
>> The discussion on the WG14 reflector seems to be settling down to a consensus position that the `_Atomic` qualifier is only syntactically a qualifier and its use designates an entirely new type. When the standard says "unqualified type", the `_Atomic` is not considered a qualification. So we should *not* be stripping the `_Atomic` as I was doing in this patch. (SC22WG14.22200 has most of the details spelled out nicely, if you have access to the reflectors.)
>
> What a strange position.  *All* qualifiers produce an "entirely new type".  But okay, if the committee wants to pretend that `_Atomic` is meaningful in return values, I guess we all have to live with that.

lol, right? :-D

>> I had asked other questions in related areas that also got answers.
>>
>> `const void func(volatile void);` -- the return type is adjusted to `void`; the parameter type is UB (by lack of specification) and we can do what we want here. We currently diagnose the parameter as being invalid: https://godbolt.org/z/9c8bTrerY. Our behavior with the parameter is consistent with GCC and EDG.
>>
>> `const int main(void)` -- this is valid and equivalent to `int main(void)`, so it should be accepted; we currently reject: https://godbolt.org/z/v43h596ev
>>
>> `const int func(void); int func(void) { }` -- this is DR423. It is valid, the composite type is `int(void)`; we give a conflicting types error: https://godbolt.org/z/Yb841r7Ex
>
> Is that only because of the type compositing rules, or are they saying that the type of the first is `const int (void)`, which is different from `int (void)`?

Quoting from the reflector question I asked,

  > Question 4
  > Also along the same thinking, what is the composite type of int
  > f(int); and const int f(const int);? Is it before or after adjustment?
  > If before adjustment, we don't seem to say anything in 6.2.7p3 about
  > the parameter type but p1 then suggests the types are not compatible
  > in the first place; if after adjustment, the composite type would be
  > int(int). There's significant compiler divergence here: Clang, GCC,
  > ppci, cc65, and TCC consider after adjusting both parameters and
  > return types, while EDG, Tendra, cproc, SDCC, and MSVC consider after
  > adjusting parameter types but not return types.
  
  According to the normative text, the qualifiers on the return type never form
  part of the type of the function at all.  I expect implementations doing otherwise
  simply failed to implement the resolution to DR#423.
  
  For parameter types, I think it's generally understood that qualifiers don't affect the
  function type (so the types are *the same type*, for the purposes of handling the
  rules on duplicate typedef declarations, not just *compatible types*), but all the
  wording actually says is that the qualifiers are disregarded "In the determination of
  type compatibility and of a composite type", leaving open the possibility that they
  form part of the function type but don't affect type compatibility or composite types.
  In any case the composite type of the two types you list must be int (int) because of
  the inclusion of "composite type" in that wording, even if you could form a case for
  int (const int) and int (int) being different (compatible) types.

I take this as meaning we *could* make `int func(void);` and `const int func(void);` have different types, but that seems like a pretty strange thing to do and we should probably just make them have the same types (so then there aren't special rules for compatibility and compositing for them).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125919/new/

https://reviews.llvm.org/D125919