Fix deprecated constant and method usage in host_env and vm crates. #8297

While compiling RustPython (specifically rustpython-host_env v0.5.0 and the vm crate), several deprecation warnings are emitted. While these do not currently break the build, they introduce technical debt, clutter CI logs, and pose potential stability and portability risks if left unaddressed.

Context & Compiler Output

The following warnings are generated during compilation:

1. libc::RLIM_NLIMITS deprecation in host_env

warning: use of deprecated constant `libc::RLIM_NLIMITS`: Not stable across OS versions
  --> crates/host_env/src/resource.rs:11:15
   |
11 | pub use libc::RLIM_NLIMITS;
   |               ^^^^^^^^^^^^

2. Atomic::fetch_update deprecation in vm

warning: use of deprecated method `rustpython_common::atomic::Atomic::<u32>::fetch_update`: renamed to `try_update` for consistency
  --> crates/vm/src/builtins/function.rs:90:10
   |
90 | ...   .fetch_update(Relaxed, Relaxed, |v| (v != 0)...
   |        ^^^^^^^^^^^^

warning: use of deprecated method `rustpython_common::atomic::Atomic::<u64>::fetch_update`: renamed to `try_update` for consistency
  --> crates/vm/src/builtins/type.rs:683:14
   |
683| ...   .fetch_update(Ordering::AcqRel, Ordering::A...
   |        ^^^^^^^^^^^^

Risks Involved

1. Cross-Platform Instability (RLIM_NLIMITS)

The libc crate explicitly marks RLIM_NLIMITS as deprecated because it is not stable across OS versions. The number of resource limits (RLIMIT_*) varies between different operating systems and even across different versions of the same OS (e.g., Linux kernel updates).

• Risk: Relying on this constant as a boundary for iterating over resource limits can lead to out-of-bounds errors, incorrect resource limit calculations, or panics when RustPython is compiled for or run on newer/older OS versions. It severely hinders cross-platform reliability.

2. Codebase Confusion and Future Breakage (fetch_update)

The internal rustpython_common::atomic::Atomic wrapper renamed fetch_update to try_update for API consistency (likely to avoid confusion with the standard library's std::sync::atomic::Atomic*::fetch_update).

• Risk: While currently just a warning, keeping deprecated methods in the codebase causes "warning fatigue" in CI. If the deprecated fetch_update method is eventually removed from rustpython_common in a future minor release, it will cause hard compilation failures. Furthermore, it confuses contributors who might look up the standard library's fetch_update and expect it to behave identically to the custom wrapper.

Proposed Solutions

Fix 1: Replace RLIM_NLIMITS in crates/host_env/src/resource.rs

Instead of exporting or using RLIM_NLIMITS as a generic upper bound, we should handle resource limits dynamically or use explicit constants.

• Action: Investigate how RLIM_NLIMITS is being used in resource.rs. If it's used to iterate over all possible limits, refactor the code to use an explicit array of supported RLIMIT_* constants for the target OS, or use conditional compilation (#[cfg(target_os = "...")]) to handle OS-specific maximums safely. Remove the pub use libc::RLIM_NLIMITS; export.

Fix 2: Rename fetch_update to try_update in vm

This is a straightforward find-and-replace to align with the updated rustpython_common API.

• Action: Update the method calls in the following files:
  • crates/vm/src/builtins/function.rs (Line 90)
  • crates/vm/src/builtins/type.rs (Line 683)

Example diff for function.rs:

-         .fetch_update(Relaxed, Relaxed, |v| (v != 0).then(|| v.wrapping_add(1)))
+         .try_update(Relaxed, Relaxed, |v| (v != 0).then(|| v.wrapping_add(1)))

Example diff for type.rs:

-             .fetch_update(Ordering::AcqRel, Ordering::Acquire, |old| {
+             .try_update(Ordering::AcqRel, Ordering::Acquire, |old| {

Action Items

• Refactor crates/host_env/src/resource.rs to remove reliance on libc::RLIM_NLIMITS.
• Rename fetch_update to try_update in crates/vm/src/builtins/function.rs.
• Rename fetch_update to try_update in crates/vm/src/builtins/type.rs.
• Run cargo build and cargo test to ensure no regressions and verify that the deprecation warnings are gone.