+/* 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
