Re: [PATCH] c++/66561 - __builtin_LINE at al. should yield constant expressions

[Martin Sebor <msebor at gmail dot com>]

> > +/* Fold __builtin_FILE() to a constant string.  */
> NIT: When we refer to functions, we don't have the trailing().  So drop
> it from the comment.
>
> > +
> > +/* Fold __builtin_FUNCTION() to a constant string.  */
> Similarly.
>
> > +
> > +/* Fold __builtin_LINE() to an integer constant.  */
> Similarly.

Okay, I'll fix it before committing once the patch is approved (or
in the next revision of the patch, whichever comes first).

> So the big question I have is why we have to treat these differently
> than __func__ __FUNCTION__ and __PRETTY_FUNCTION__.
>
> Which leads me to:
>
> constexpr_fn_retval which has:
>
>     case DECL_EXPR:
>        {
>          tree decl = DECL_EXPR_DECL (body);
>          if (TREE_CODE (decl) == USING_DECL
>              /* Accept __func__, __FUNCTION__, and __PRETTY_FUNCTION__.  */
>              || DECL_ARTIFICIAL (decl))
>            return NULL_TREE;
>          return error_mark_node;
>        }
>
> Is the distinction here that the _builtin_XXX are essentially functions,
> yet the others are _DECLs?  Thus we have to fold the builtin function so
> that it is considered a constant?

Yes, the built-ins are functions that return a pointer and the three
symbols above are objects, basically static local arrays represented
as "artificial" VAR_DECLs, and they need to be folded to be usable
in constant expressions (in both C++ and C).

IIUC, the piece of code quoted above is a workaround put in place
for the C++ 11 restriction that constexpr functions cannot declare
local variables, but users expect to be able to refer to __func__
and related (bug 55425).  The code path only seems to be exercised
in C++ 11 mode, not later.  There's also the problem of C++ not
allowing static local variables in constexpr functions, and I think
there's another workaround for that somewhere.

Martin