Adding + Fixing Clippy rules to better align with #[no_std]

[terryluan12]

Hey there, because it seemed fairly straightforward, I ended up just adding it; I hope that's alright! Please let me know if there is anything I should change.

This addresses issue #6380

[coderabbitai[bot]]

[!IMPORTANT]

Review skipped

Too many files!

35 files out of 185 files are above the max files limit of 150.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions[bot]]

Code has been automatically formatted

The code in this PR has been formatted using cargo fmt --all. Please pull the latest changes before pushing again:

git pull origin main

[terryluan12]

Most things were straightforward replacing std:: with their respective core::/alloc:: equivalents. There were a couple of cases where I had to add additional specifiers (::alloc:: for example)

In crates/stdlib/src/ssl/cert.rs and vm/src/anystr.rs I also condensed some of the imports into a general use statement at the top, just because I thought it would be neater. Let me know if I should undo those changes

[youknowone]

Thank you so much! And the changes in cert.rs and anystr.rs is also looking reasonable. Could you also check jit crate? I don't think jit is available on no_std environment. Either skipping the lint rule for jit crate or fixing them will be good.

[youknowone]

To prevent further conflict, if you create a separated PR without the cargo.toml changes, I will immediately merge it

[diffray-bot]

Changes Summary

This PR addresses issue #6380 by systematically migrating the RustPython codebase to prefer core:: and alloc:: imports over std:: imports where appropriate, following Rust best practices for no-std compatibility. The work involves 184 changed files across all crates (codegen, common, compiler-core, stdlib, vm, etc.) and concludes with an auto-formatting pass to maintain consistency.

Type: refactoring

Components Affected: codegen, common, compiler-core, compiler, derive-impl, derive, literal, sre_engine, stdlib, vm, venvlauncher, examples

Files Changed

File	Summary	Change	Impact
crates/common/src/str.rs	Replaced std:: imports with core:: equivalents (ops, fmt, slice, iter, mem) where applicable, improved no-std support	✏️	🔴
crates/stdlib/src/array.rs	Migrated std:: to core:: and alloc:: for mem operations, memory layout calculations, and slice construction	✏️	🔴
crates/codegen/src/lib.rs	Added extern crate alloc declaration for proper allocation support in no-std context	✏️	🟡
crates/compiler-core/src/lib.rs	Added extern crate alloc declaration	✏️	🟡
crates/common/src/lib.rs	Added extern crate alloc declaration	✏️	🟡
Cargo.toml	Updated workspace lints to include clippy rules for std_instead_of_core, alloc_instead_of_core, std_instead_of_alloc	✏️	🟡

Architecture Impact

• New Patterns: no-std compatibility, core/alloc crate separation, standards-based import organization
• Dependencies: Added: clippy lint rules (std_instead_of_core, std_instead_of_alloc, alloc_instead_of_core)
• Coupling: Reduces coupling to std library by preferring core:: and alloc:: modules, enabling better no-std support and potentially facilitating WASM targets

Risk Areas: Widespread import changes across 184 files could introduce subtle runtime behavior changes if core:: and std:: implementations differ, Changes to memory safety operations (mem::size_of, mem::swap, slice operations) need verification that no subtle bugs were introduced, Clippy lint enforcement (alloc_instead_of_core, std_instead_of_alloc) could break existing tooling if lints are too strict, Import reordering (as part of rustfmt) could affect code readability or introduce merge conflicts

Suggestions

• Verify that no-std compilation works correctly with these changes (test with cargo build --no-default-features)
• Run full test suite to ensure behavioral equivalence between std:: and core:: imports
• Check that all memory safety operations (ManuallyDrop, size_of, swap, etc.) have identical semantics after refactoring
• Review the handling of platform-specific features (Windows, WASM) to ensure no regressions
• Validate that the new Cargo.toml lint rules don't incorrectly flag legitimate uses of std

_{Full review in progress... | Powered by diffray}

[diffray-bot]

Review Summary

Free public review - Want AI code reviews on your PRs? Check out diffray.ai

Validated 10 issues: 4 kept (valid performance/quality concerns), 6 filtered (speculative, incorrect analysis, or low value)

Issues Found: 4

📊 2 unique issue type(s) across 4 location(s)

📋 Full issue list (click to expand)

🟠 HIGH - Multiple expect() calls on module initialization without error handling (2 occurrences)

Agent: rust

Category: quality

Why this matters: This pattern commonly causes runtime bugs.

📍 View all locations

File	Description	Suggestion	Confidence
crates/stdlib/src/array.rs:8-27	The make_module function uses chained .expect() calls on attribute lookups which will panic if Pytho...	Return PyResult<PyRef<PyModule>> and use ? operator to propagate errors properly instead of panickin...	75%
crates/stdlib/src/mmap.rs:716-731	The as_bytes_mut and as_bytes methods call expect() which could panic if the mmap has been closed. O...	Return PyResult or use check_valid() pattern consistently. The check_valid() method already exists a...	70%

Rule: rust_unwrap_panic

---

🟡 MEDIUM - Redundant cloning in tuple flattening operation (2 occurrences)

Agent: performance

Category: performance

Why this matters: Poor performance degrades user experience.

📍 View all locations

File	Description	Suggestion	Confidence
crates/vm/src/frame.rs:1590-1598	The flatten_tuples method clones each element from tuple iterators. For PyObjectRef (reference-count...	Verify if cloning is necessary. If tuples need to be consumed/ownership transferred, consider using ...	65%
crates/vm/src/frame.rs:140-150	The closure.iter().cloned() in Frame::new clones closure cell references. This happens at frame crea...	Examine if PyCellRef cloning is cheap (it's likely a reference-counted type). If so, this is accepta...	60%

Rule: rust_clone_in_loop

---

ℹ️ 4 issue(s) outside PR diff (click to expand)

These issues were found in lines not modified in this PR.

🟠 HIGH - Multiple expect() calls on module initialization without error handling (2 occurrences)

Agent: rust

Category: quality

Why this matters: This pattern commonly causes runtime bugs.

📍 View all locations

File	Description	Suggestion	Confidence
crates/stdlib/src/array.rs:8-27	The make_module function uses chained .expect() calls on attribute lookups which will panic if Pytho...	Return PyResult<PyRef<PyModule>> and use ? operator to propagate errors properly instead of panickin...	75%
crates/stdlib/src/mmap.rs:716-731	The as_bytes_mut and as_bytes methods call expect() which could panic if the mmap has been closed. O...	Return PyResult or use check_valid() pattern consistently. The check_valid() method already exists a...	70%

Rule: rust_unwrap_panic

---

🟡 MEDIUM - Redundant cloning in tuple flattening operation (2 occurrences)

Agent: performance

Category: performance

Why this matters: Poor performance degrades user experience.

📍 View all locations

File	Description	Suggestion	Confidence
crates/vm/src/frame.rs:1590-1598	The flatten_tuples method clones each element from tuple iterators. For PyObjectRef (reference-count...	Verify if cloning is necessary. If tuples need to be consumed/ownership transferred, consider using ...	65%
crates/vm/src/frame.rs:140-150	The closure.iter().cloned() in Frame::new clones closure cell references. This happens at frame crea...	Examine if PyCellRef cloning is cheap (it's likely a reference-counted type). If so, this is accepta...	60%

Rule: rust_clone_in_loop

---

---

_{Review ID: a7c99827-4b9a-4d34-bb85-366902dc73b2 Rate it 👍 or 👎 to improve future reviews | Powered by diffray}

[terryluan12]

Hey, sorry about the late response! I just updated jit, so everything should be good (unless there are other crates I'm missing which I'm currently looking through). I'm unsure about how I should merge the conflicts. Am I good to just accept the incoming changes?

[terryluan12]

(Wrote a comment on the wrong PR. This one should be fine to merge, once conflicts are resolved)

[youknowone]

@terryluan12 I think accepting new code, change std again to core is more easy in this case

[terryluan12]

Sounds good. Just fixed the conflicts!