[PATCH] D129488: [Sema] Delay evaluation of std::source_location::current() in default arguments
James Y Knight via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Aug 31 15:05:46 PDT 2022
jyknight added a comment.
In D129488#3761478 <https://reviews.llvm.org/D129488#3761478>, @ilya-biryukov wrote:
> In D129488#3761398 <https://reviews.llvm.org/D129488#3761398>, @jyknight wrote:
>
>> I believe this should print `fn=14 fn2=14`. I don't see how we can get that by special-casing calls to `std::source_location::current`, and indeed, with this version of the patch, the program instead prints `fn=14 fn2=9`.
>
> There is another issue in Clang that prevents it from producing correct results with this patch. We should not evaluate immediate calls inside default arguments of immediate function parameters as they are deemed to be inside the immediate function context <https://eel.is/c++draft/expr.const#14.1>. Clang currently evaluates these calls as all parameter scopes are `PotentiallyEvaluatedIfUsed` and `ImmediateFunctionContext` is a different value inside the same enumeration :)
OK...So...
If the correct rule is that consteval functions must be immediately evaluated even when used in a default arg of a non-consteval function (rather than deferring evaluation to the callsite, as would otherwise be the rule for default args!), then GCC's behavior for "fn3" in your example https://gcc.godbolt.org/z/P1x8PGsh6 makes sense. And, yea, also Clang's _current_ behavior for `current()` makes sense! Because `current` is not actually generating the source location itself -- the //actual// source location is coming from a builtin call in a default arg of `current()`...it's only a wrapper, just like `fn()` is a wrapper around `current()`.
But, "makes sense" (from implementation point of view) doesn't mean "useful"...which is why you're adding a special case for it. And why GCC also did.
This is really quite awful.
The more I look at this, the more I feel like, if all the above behaviors are correct, source_location::current() simply shouldn't be marked consteval at all. If it was constexpr, instead, it'd work great _without_ needing any special-casing, because the "must evaluate immediately upon seeing function definition even in default arg position" wouldn't apply to it. And that's the behavior we //want// from it!
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D129488/new/
https://reviews.llvm.org/D129488
More information about the cfe-commits
mailing list