Add process_info(Pid, label) for retrieving the process label

[bjorng]

The only documented way to retrieve the label for a process was by calling proc_lib:get_label/1.

This commit teaches process_info/2 the option label for retrieving the process label. This is especially useful when one needs to retrieve other process info items at the same time. For example:

process_info(Pid, [label,registered_name])

[github-actions]

CT Test Results

    3 files    143 suites   48m 31s ⏱️
1 596 tests 1 547 ✅ 49 💤 0 ❌
2 340 runs  2 266 ✅ 74 💤 0 ❌

Results for commit 2a8c77b.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[josevalim]

Could the new process_info(Pid, {dictionary, '$label'}) be used instead? If we don't want to expose the key, then maybe we could have proc_lib:label_key/0? The benefit of doing this route is that it would also work with $ancestors and other keys, without having to touch the runtime every time. :)

[rickard-green]

@josevalim

Could the new process_info(Pid, {dictionary, '$label'}) be used instead? If we don't want to expose the key, then maybe we could have proc_lib:label_key/0? The benefit of doing this route is that it would also work with $ancestors and other keys, without having to touch the runtime every time. :)

Currently the only documented way of retrieving the label is by calling proc_lib:get_label/1. proc_lib:get_label/1 internally looks up the label in the dictionary using process_info(Pid, {dictionary, '$process_label'}). We, however, do not want to document and support that. The point of introducing the label argument to process_info/2 is that we want to be able to move it away from the dictionary in the future.