On Tue, 30 Jul 2019, Martin Sebor wrote: > On 7/30/19 1:13 AM, Akshat Garg wrote: > > Hi, > > This patch includes C front-end code for a type qualifier _Dependent_ptr. > > Just some very high-level comments/questions. I only followed > the _Dependent_ptr discussion from a distance and I'm likely > missing some context so the first thing I looked for in this > patch is documentation of the new qualifier. Unless it's
The first question for any new thing that is syntactically a qualifier is: is it intended generally to be counted as a qualifier where the standard refers to qualified type, the unqualified version of a type, etc.? Or is it, like _Atomic, a qualifier only syntactically and generally excluded from references to qualifiers? For the _Atomic implementation I had to go through all the references to qualifiers or TYPE_MAIN_VARIANT in the front end and consider in each case whether it handled _Atomic correctly, given that _Atomic is not counted as a qualifier in the standard (so the unqualified version of const _Atomic int is _Atomic int not int, and so can't be derived simply by using TYPE_MAIN_VARIANT, for example). Some cases didn't need changing because the handling (e.g. diagnostic for different types) was still appropriate for _Atomic even though not formally a qualifier, but plenty did need changing and associated tests added. Such a check of front end code is probably unavoidable (before a change is ready for trunk, not necessarily for an initial rough RFC patch) for any new qualifier, whether it counts as a qualifier in standard terms or not (and the patch reviewer will need to do their own check of references to qualifiers or TYPE_MAIN_VARIANT that didn't get changed by the patch), but the answer to that question helps indicate whether the default is to expect code to need changing for the new qualifier or not. > you point to it? (In that case, or if a proposal is planned, > the feature should probably either only be available with > -std=c2x and -std=gnu2x or a pedantic warning should be issued There should not be any -std=c2x (flag_isoc2x) conditionals simply based on "a proposal is planned". flag_isoc2x conditionals (pedwarn_c11 calls, etc.) should be for cases where a feature is *accepted and committed into the C2x branch of Jens's git repository for the C standard*, not for something that might be proposed, or is proposed, but doesn't yet have specific text integrated into the text of the standard. If something is simply proposed *and we've concluded it's a good feature to have as an extension in any case* then you have a normal pedwarn-if-pedantic (no condition on standard version) as for any GNU extension (and flag_isoc2x conditions / changes to use pedwarn_c11 instead can be added later if the extension is added to the standard). -- Joseph S. Myers jos...@codesourcery.com
