Skip to content

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

Merged
youknowone merged 12 commits intoRustPython:mainfrom
terryluan12:main
Dec 30, 2025
Merged

Adding + Fixing Clippy rules to better align with #[no_std]#6570
youknowone merged 12 commits intoRustPython:mainfrom
terryluan12:main

Conversation

@terryluan12
Copy link
Contributor

@terryluan12 terryluan12 commented Dec 29, 2025

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
Copy link
Contributor

coderabbitai bot commented Dec 29, 2025

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

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

@github-actions
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

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

@diffray-bot
Copy link

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
Copy link

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> 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> 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
Copy link
Contributor Author

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 terryluan12 mentioned this pull request Dec 29, 2025
@terryluan12
Copy link
Contributor Author

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

@youknowone
Copy link
Member

youknowone commented Dec 29, 2025

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

@terryluan12
Copy link
Contributor Author

terryluan12 commented Dec 29, 2025

Sounds good. Just fixed the conflicts!

youknowone and others added 2 commits December 30, 2025 12:40
Co-authored-by: Jeong, YunWon <69878+youknowone@users.noreply.github.com>
Copy link
Member

@youknowone youknowone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@terryluan12 Thank you so much for working on this huge task!

@youknowone youknowone merged commit 1464d5c into RustPython:main Dec 30, 2025
13 checks passed
@youknowone youknowone mentioned this pull request Dec 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants