Adding + Fixing Clippy rules to better align with #[no_std] by terryluan12 · Pull Request #6570 · RustPython/RustPython · GitHub

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

…of_core clippy rules * Manually changed part of the code to use core/alloc

* Imported Range in vm/src/anystr.rs

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.

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

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

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.

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

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

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

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?

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

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

Sounds good. Just fixed the conflicts!

Co-authored-by: Jeong, YunWon <69878+youknowone@users.noreply.github.com>

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

terryluan12 added 6 commits December 28, 2025 21:35

* Added alloc_instead_of_core, std_instead_of_alloc, and std_instead_…

61f9c08

…of_core clippy rules * Manually changed part of the code to use core/alloc

Merge branch 'main' of https://github.com/terryluan12/RustPython

f88a0ac

use clippy --fix to fix issues in stdlib

a3b0599

* Used clippy --fix to fix issues in vm

37a0fe0

* Imported Range in vm/src/anystr.rs

* Used clippy --fix to fix issues in common

abcc9fa

Finished migrating the rest of the warnings manually

ae6f6d8

Auto-format: cargo fmt --all

86957cc

terryluan12 and others added 2 commits December 29, 2025 11:54

Updated jit to use core/alloc where available

e94e28a

Auto-format: cargo fmt --all

7a4e1bb

terryluan12 mentioned this pull request Dec 29, 2025

Add tests asyncio #6584

Closed

Merge branch 'main' into main

c96ecb1

youknowone requested changes Dec 30, 2025

View reviewed changes

Comment thread Cargo.toml Outdated

Comment thread Cargo.toml Outdated

youknowone and others added 2 commits December 30, 2025 12:40

Apply suggestions from code review

7d2868c

Removed teh EOL

c51cdb2

Co-authored-by: Jeong, YunWon <69878+youknowone@users.noreply.github.com>

youknowone approved these changes Dec 30, 2025

View reviewed changes

youknowone merged commit 1464d5c into RustPython:main Dec 30, 2025
13 checks passed

youknowone mentioned this pull request Dec 30, 2025

finish no_std clippy #6587

Merged

Adding + Fixing Clippy rules to better align with #[no_std] by terryluan12 · Pull Request #6570 · RustPython/RustPython · GitHub

Uh oh!

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

Adding + Fixing Clippy rules to better align with #[no_std]#6570youknowone merged 12 commits intoRustPython:mainRustPython/RustPython:mainfrom terryluan12:mainterryluan12/RustPython:mainCopy head branch name to clipboard

Conversation

terryluan12 commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai Bot commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

github-actions Bot commented Dec 29, 2025

Uh oh!

terryluan12 commented Dec 29, 2025

Uh oh!

youknowone commented Dec 29, 2025

Uh oh!

youknowone commented Dec 29, 2025

Uh oh!

diffray-bot commented Dec 29, 2025

Changes Summary

Uh oh!

diffray-bot commented Dec 29, 2025

Review Summary

Issues Found: 4

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

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

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

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

Uh oh!

terryluan12 commented Dec 29, 2025

Uh oh!

terryluan12 commented Dec 29, 2025

Uh oh!

youknowone commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

terryluan12 commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

youknowone left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

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

terryluan12 commented Dec 29, 2025 •
edited
Loading

coderabbitai Bot commented Dec 29, 2025 •
edited
Loading

youknowone commented Dec 29, 2025 •
edited
Loading

terryluan12 commented Dec 29, 2025 •
edited
Loading