This patch (for C) is setting c_inhibit_evaluation_warnings and
in_remove_qualifiers and doing corresponding use of pop_maybe_used, but I
don't see the need for that. Expressions within the argument to
__remove_qualifiers are evaluated exactly if they would be evaluated in
the containing
On Sat, 9 Sep 2017, Jason Merrill wrote:
> > +@code{__remove_qualifiers} takes a typename as an argument:
>
> I think it would be better to use the term "type-id" here, to avoid
> confusion with "type-name", which is only a single identifier.
There's no such thing as a type-id in C, and
On Fri, Sep 1, 2017 at 2:46 PM, Marek Polacek wrote:
> @@ -16960,6 +16961,24 @@ cp_parser_simple_type_specifier (cp_parser* parser,
>
>return type;
>
> +case RID_REMOVE_QUALS:
> + /* Consume the `__remove_qualifiers' token. */
> + cp_lexer_consume_token
On Thu, Aug 31, 2017 at 04:38:27PM +, Joseph Myers wrote:
> I think the documentation needs to say (and the tests need to test) that
> this produces a non-atomic type (like lvalue-to-rvalue conversion), if
> that's the intent for how it handles atomic types, since _Atomic is
> syntactically
I think the documentation needs to say (and the tests need to test) that
this produces a non-atomic type (like lvalue-to-rvalue conversion), if
that's the intent for how it handles atomic types, since _Atomic is
syntactically a qualifier but largely not treated like one in the
standard.
--
After a long time, I'm finally sending the revisited patch dealing with these
two PRs. To quickly recap, users were looking for a typeof variant that
strips type qualifiers. I sent a path adding __typeof_noqual, but a discussion
ensued and it's been concluded that we'd rather go a different way,