[DO NOT MERGE] Almost complete rustls integration rewrite - #8007

crates/stdlib/src/ssl/compat.rs (2)

368-381: ⚡ Quick win

Using .expect() on fallible operations in error handling path.

Lines 369-370 use .expect("unlikely to happen") on create_pem_ssl_error. While attribute-setting failures are indeed rare (typically only on OOM), panicking in an error-handling path is undesirable. Consider using .unwrap_or_else() to fall back to a simpler error without attributes, matching the pattern used elsewhere in this file (e.g., line 386).

♻️ Proposed fix to avoid panic in error path

-            Self::PemLib(msg) => Self::create_pem_ssl_error(vm, format!("PEM lib: {msg}"))
-                .expect("unlikely to happen"),
+            Self::PemLib(msg) => Self::create_pem_ssl_error(vm, format!("PEM lib: {msg}"))
+                .unwrap_or_else(|_| Self::create_plain_ssl_error(vm, format!("PEM lib: {msg}"))),

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/stdlib/src/ssl/compat.rs` around lines 368 - 381, The PemLib arm
panics by calling .expect(...) on the fallible create_pem_ssl_error; change it
to handle failure like other arms by using unwrap_or_else to fall back to a
simpler error (e.g., call Self::create_plain_ssl_error with a "PEM lib: {msg}"
message) so create_pem_ssl_error(vm, format!("PEM lib:
{msg}")).unwrap_or_else(|_| Self::create_plain_ssl_error(vm, format!("PEM lib:
{msg}"))). Ensure you update the Self::PemLib match arm to use unwrap_or_else
and reference create_pem_ssl_error and create_plain_ssl_error accordingly.

---

225-252: 💤 Low value

Audit rustls::PeerIncompatible coverage vs rustls 0.23 variants (crates/stdlib/src/ssl/compat.rs, from_rustls match ~225-252)

The mapping only covers some rustls::PeerIncompatible variants in rustls 0.23; the _ => arm currently handles other existing variants (e.g., ExtendedMasterSecretExtensionRequired, IncorrectCertificateTypeExtension, NullCompressionRequired, ServerSentHelloRetryRequestWithUnknownExtension, UnsolicitedCertificateTypeExtension, ServerRejectedEncryptedClientHello(...)) by falling back to Self::Ssl(format!("peer is incompatible: {peer_err:?}")) rather than an OpenSSL reason code. Add explicit arms for the remaining variants or document that this generic fallback is intentional (since the enum is non-exhaustive).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/stdlib/src/ssl/compat.rs` around lines 225 - 252, The match over
rustls::PeerIncompatible in from_rustls currently falls through to a generic
Ssl(...) fallback for many 0.23 variants; update the match to explicitly handle
the remaining PeerIncompatible variants (e.g.,
ExtendedMasterSecretExtensionRequired, IncorrectCertificateTypeExtension,
NullCompressionRequired, ServerSentHelloRetryRequestWithUnknownExtension,
UnsolicitedCertificateTypeExtension, ServerRejectedEncryptedClientHello, etc.)
and map each to the appropriate OpenSSL reason constant using
Self::OpenSslReason(SSL_R_...) where sensible, or if you intentionally want a
generic fallback keep the fallback but add a comment documenting that the enum
is non_exhaustive and the generic Self::Ssl(format!(...)) is deliberate; touch
the match in from_rustls so all current PeerIncompatible variants are either
explicitly mapped to an SSL_R_* constant (using the same style as existing arms)
or a documented fallback is left.

crates/vm/src/vm/mod.rs (1)

2378-2401: ⚡ Quick win

Cover the first-load hook path too.

This test only exercises the sys.modules cache-hit case because sys is already imported before Line 2383. The downstream ssl hook in crates/stdlib/src/rustls.rs:164-177 is registered during module execution and depends on the initial _find_and_load path, so a regression there would currently slip through.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/vm/src/vm/mod.rs` around lines 2378 - 2401, The test only covers the
cache-hit path; update module_loaded_hook_can_patch_imported_module to also
exercise the initial load path by registering the hook (mark_module_loaded)
before ensuring the target module is not present in sys.modules and then
importing it so the interpreter takes the _find_and_load path; specifically, in
the vm.enter closure call vm.register_module_loaded_hook("sys",
mark_module_loaded) then remove the "sys" entry from sys.modules (via the VM sys
module/object APIs) or choose a fresh module name that is guaranteed not to be
pre-imported, then call vm.import(...) to trigger the initial-load hook and
assert the "__rustpython_module_loaded_hook_ran__" attribute as the existing
test does (referencing module_loaded_hook_can_patch_imported_module,
mark_module_loaded, vm.register_module_loaded_hook, and vm.import).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes