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

Thu Jun 2 12:25:08 PDT 2022

aaron.ballman added a comment.

In D125919#3554078 <https://reviews.llvm.org/D125919#3554078>, @delcypher wrote:

> @aaron.ballman Hey I just saw this change and had questions about it. For others looking I think the resolution to DR423 is in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1863.pdf, I found https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_423 hard to parse.
>
> 1. It looks like we're completely dropping qualifiers on the return types of function in C. If that's the case, what's even the point of having qualifiers on return types of functions?

As best I can tell, there is no point to having a qualified return type for a function in C because it is effectively unobservable, which is likely why qualifiers are removed from the function return type per spec. C2x 6.7.3p5 says "The properties associated with qualified types are meaningful only for expressions that are lvalues." and a function's returned value is never an lvalue in C. I say "effectively" unobservable because there can still be language extensions that make the return type more observable.

> 2. Reading DR423 I see the problem but I don't understand why the desire to make `_Generic` work better in the presence of qualifiers means that qualifiers on function return types have to be dropped in all contexts. Couldn't this just be a thing that is done inside `_Generic` and no where else?

The reason qualifiers are to be dropped is because of C2x 6.7.6.3p4, which was what was updated by DR423 to say: "If, in the declaration "T D1 <https://reviews.llvm.org/D1>", D1 <https://reviews.llvm.org/D1> has the form D ( parameter-type-list_opt ) attribute-specifier-sequence_opt and the type specified for ident in the declaration "T D" is "derived-declarator-type-list T", then the type specified for ident is "derived-declarator-type-list function returning the unqualified version of T". Note how the type specified for the function is returning the unqualified version of T. This will impact more than just `_Generic`; for example `__builtin_types_compatible_p()` is also affected: https://godbolt.org/z/1bhcvhv3M

However, I reverted the changes in this patch in c745f2ce6c03bc6d1e59cac69cc15923d4400191 <https://reviews.llvm.org/rGc745f2ce6c03bc6d1e59cac69cc15923d4400191> as I don't think they're correct. I've got some open questions on the WG14 reflectors regarding this function type rewriting exercise, but I think my dropping of the `_Atomic` qualifier is likely wrong in this patch and the fact that we're losing source fidelity in the AST is definitely an issue. The subject of https://github.com/llvm/llvm-project/issues/39595 was the behavior of the `_Atomic` specifier in a `_Generic` selection; when I realized we don't fully implement DR423, I mistakenly connected the issue with the DR. But now that I no longer think the `_Atomic` qualifier should be dropped as I was doing, these changes really don't address the issue in `_Generic`.

> Sorry if these are silly questions and if I've misunderstood something, I saw n1863 say "functions return unqualified types" and I was very surprised.

These are not at all silly questions, so thank you for asking them!

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125919