erlang:hibernate/0 --> erlang:process_info(Pid, current_function) returns incorrect results

[Maria-12648430]

Describe the bug
If a function in a compiled module calls the new erlang:hibernate/0, a call to erlang:process_info(Pid, current_function) returns the calling module/function instead of {erlang, hibernate, 0}.

If a function in a compiled module spawns a process with an anonymous function which calls erlang:hibernate/0, erlang:process_info(Pid, current_function) returns the module and the internal name of the anonymous function instead of {erlang, hibernate, 0}.
However, when doing the same spawn in the shell, erlang:process_info(Pid, current_function) correctly returns {erlang, hibernate, 0}.

If a spawn is made via the MFA form, ie Pid=spawn(erlang, hibernate, []), erlang:process_info(Pid, current_function) correctly returns {erlang, hibernate, 0} both if the spawn was made from a function in a compiled module or in the shell.

To Reproduce

-module(test).
-compile(export_all).

test1() ->
    erlang:hibernate().

test2() ->
    spawn(fun() -> erlang:hibernate() end).

test3() ->
    spawn(erlang, hibernate, []).

In the shell:

1> P1=spawn(test, test1, []).
<0.91.0>
2> erlang:process_info(P1, current_function).
{current_function,{test,test1,0}}

3> P2=test:test2().
<0.93.0>
4> erlang:process_info(P2, current_function).
{current_function,{test,'-test2/0-fun-0-',0}}
5> P3=spawn(fun() -> erlang:hibernate() end).
<0.95.0>
6> erlang:process_info(P3, current_function).
{current_function,{erlang,hibernate,0}}

7> P4=test:test3().
<0.100.0>
8> erlang:process_info(P4, current_function).
{current_function,{erlang,hibernate,0}}
5> P5=spawn(erlang, hibernate, []).
<0.105.0>
6> erlang:process_info(P5, current_function).
{current_function,{erlang,hibernate,0}}

Expected behavior
erlang:process_info(Pid, current_function) always returns {erlang, hibernate, 0} for all above cases.

Affected versions
OTP 28

[jhogberg]

Thanks for your report! Conceptually, the caller does not wait in erlang:hibernate/0, it returns to the caller and just-so-happens to not run again until a message arrives. It does this for two reasons; the first is that reporting erlang:hibernate/0 in current_function is less helpful than informing about the calling context (consider observer), the second is that it makes the implementation trivial.

That the apply/spawn versions leads to current_function being erlang:hibernate/0 is simply because that is the current function in that case:

hibernate() ->
    %% This function is a fallback used on apply/3; the loader turns this
    %% remote call of ourselves into a special instruction.
    erlang:hibernate().

If we had instead called erts_internal:flurb/0 which hibernated in turn, current_function would have been erts_internal:flurb/0.