Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

[Jason Merrill <jason@redhat.com>]

On 8/10/23 11:35, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping this patch.  Reposting it as I found a typo in the
> documentation - s/builtin-in/built-in/.  Bootstrapped/regtested again
> on x86_64-linux and i686-linux, ok for trunk?
> 
> On Mon, Jun 12, 2023 at 09:57:17PM +0200, Jakub Jelinek via Gcc-patches wrote:
>> As mentioned in my stdckdint.h mail, __builtin_classify_type has
>> a problem that argument promotion (the argument is passed to ...
>> prototyped builtin function) means that certain type classes will
>> simply never appear.
>> I think it is too late to change how it behaves, lots of code in the
>> wild might rely on the current behavior.

Hmm, you really think there's any code at all in the wild relying on 
__builtin_classify_type + array/function decay?  It's a (previously) 
undocumented built-in, I wouldn't expect anyone outside the project to 
be using it.  So at first glance I'd be inclined to fix it whether or 
not we also allow it to accept a type.  But I don't actually know how 
it's used, so could well be wrong...

> --- gcc/cp/parser.cc.jj	2023-06-06 20:02:35.631211230 +0200
> +++ gcc/cp/parser.cc	2023-06-12 16:19:04.892202240 +0200
> @@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.
>   #include "c-family/known-headers.h"
>   #include "contracts.h"
>   #include "bitmap.h"
> +#include "builtins.h"
>   
>   \f
>   /* The lexer.  */
> @@ -7850,6 +7851,50 @@ cp_parser_postfix_expression (cp_parser
>   		  = parser->non_integral_constant_expression_p;
>   		parser->integral_constant_expression_p = false;
>   	      }
> +	    else if (TREE_CODE (stripped_expression) == FUNCTION_DECL
> +		     && fndecl_built_in_p (stripped_expression,
> +					   BUILT_IN_CLASSIFY_TYPE))
> +	      {
> +		/* __builtin_classify_type (type)  */
> +		auto cl1 = make_temp_override
> +			     (parser->type_definition_forbidden_message,
> +			      G_("types may not be defined in "
> +				 "%<__builtin_classify_type%> calls"));
> +		auto cl2 = make_temp_override
> +			     (parser->type_definition_forbidden_message_arg,
> +			      NULL);
> +		auto cl3 = make_temp_override (parser->in_type_id_in_expr_p,
> +					       true);
> +		cp_evaluated ev;
> +		++cp_unevaluated_operand;
> +		++c_inhibit_evaluation_warnings;

These three lines seem unnecessary for parsing a type.

> +		tentative_firewall firewall (parser);

I think you only need a tentative_firewall if you're going to call 
cp_parser_commit_to_tentative_parse yourself, which you don't.

Jason