linux_l4re: annotate unstable *NUM constants

[dybucc]

Description

Constants matching the *NUM naming scheme whose purpose is that of denoting a limit among other symbols have been deprecated in this patch. This stems from the deprecation efforts in #3131.

This is a follow up PR to #5120.

Sources

• The WCTYPE_ALNUM constant in the TEEOS tree has not been deprecated because I could not find the symbol in the OpenHarmony SDK. I tried with all versions of the latest SDK as released in both their GitHub and their Gitee, but I had no luck after running rg with the following command.

  rg -C 10 -S -g "*.h" -e "WCTYPE_ALNUM"

• The PT_NUM in the Fuchsia source constant has not been deprecated because it does not seem to be used as a limit of any sort.

  https://cs.opensource.google/search?q=pt_num&sq=&ss=fuchsia%2Ffuchsia:zircon%2F

• The AT_PHNUM constant in NetBSD, FreeBSD, Android and Linux/L4RE has not been deprecated as the accompanying comments mention they are supposed to denote some number of entries, which I assume as not implying the type of "limit" value we're looking to deprecate.

  https://github.com/search?q=repo%3ANetBSD%2Fsrc%20AT_PHNUM&type=code
  https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-src%20AT_PHNUM&type=code
  https://github.com/search?q=repo%3Atorvalds%2Flinux%20at_phnum&type=code
  https://cs.android.com/search?q=at_phnum&sq=&ss=android%2Fplatform%2Fsuperproject

• The VFS_MAXTYPENUM FreeBSD constant has not been deprecated because it does not seem to be used as a the type of "limit" value we've deprecated in related PRs.

  https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-src+VFS_MAXTYPENUM&type=code

• The B_DEV_BAD_DRIVE_NUM constant under the Haiku tree has not been deprecated as it seems to just be another enum variant among a few other constants denoting errors.

  https://github.com/search?q=repo%3Ahaiku%2Fhaiku%20B_DEV_BAD_DRIVE_NUM&type=code

• The ELFCLASSNUM and EV_NUM Linux and L4RE constant have been deprecated as the context in which they are used in the upstream codebase and the fact they are trailing constants after two other symbols, implies they're the type of "limit" values we would want to deprecate.

  https://github.com/search?q=repo%3Atorvalds%2Flinux%20ELFCLASSNUM&type=code
  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/elf.h#L380

• The ELFDATANUM Linux and L4RE constant has not been deprecated because I could not find it in neither one of the Linux nor L4RE upstream repos (neither kernels.)

• The ET_NUM and PT_NUM constants in Linux and L4RE have not been deprecated because I could not find them in neither one of the Linux nor L4RE repos.

  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/elf.h#L72
  https://github.com/search?q=repo%3AL4Re%2Ffiasco%20%2F%5B%5E%5B%3Aalpha%3A%5D%5Det_num%2F&type=code
  https://github.com/search?q=repo%3Atorvalds%2Flinux+PT_NUM+path%3A%2F%5Einclude%5C%2F%2F&type=code
  https://github.com/search?q=repo%3AL4Re%2Ffiasco+pt_num&type=code

• The ED_INVALID_RECNUM constant in the GNU Hurd was not deprecated as the comment alongside its declaration does seem to imply it's not the type of "limit" value we're looking to depreacte.

  https://cgit.git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/bits/errno.h?h=t/sysvshm#n407

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

[dybucc]

CI actually passes. There seems to be an issue with a glob import that is not used, but this has not
been changed in the patch (it's not even part of it, for that matter.) For some reason, rebasing
onto main with dependabot updates has ended up with a warning across all of my open PRs due to
that one (now apparently unused) import.

[tgross35]

Needs the same doc comment updates
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[dybucc]

@tgross35 The documentation link is wrong. There was an analogous PR with the same link. That was not caught then. What should the link be?

@rustbot ready review

[tgross35]

I just haven't merged the PR adding that section yet, it should be correct once that happens. Doc checks only run on a handful of targets.

[tgross35]

LGTM once that PR merges

View changes since this review