Use const fn where possible
#5894
Conversation
WalkthroughThis pull request systematically updates a wide range of function and method signatures across the codebase, converting regular functions to Changes
Sequence Diagram(s)Omitted: The changes are mechanical signature updates and do not introduce or modify control flow or features. Possibly related PRs
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Clippy (1.86.0)error: failed to load source for dependency Caused by: Caused by: Caused by: 📜 Recent review detailsConfiguration used: .coderabbit.yml 📒 Files selected for processing (47)
✅ Files skipped from review due to trivial changes (5)
🚧 Files skipped from review as they are similar to previous changes (41)
🧰 Additional context used📓 Path-based instructions (1)`**/*.rs`: Follow the default rustfmt code style (`cargo fmt` to format) Always ...
📄 Source: CodeRabbit Inference Engine (.github/copilot-instructions.md) List of files the instruction was applied to:
🧠 Learnings (1)compiler/src/lib.rs (2)⏰ Context from checks skipped due to timeout of 90000ms (11)
🔇 Additional comments (1)
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (3)
vm/sre_engine/src/string.rs (1)
226-265: Useadd/subinstead ofoffsetto regain const-eval & avoid UB
ptr.offset(±1)works at run-time, but raw-pointeroffsetis not const-stable
yet. The brand-newconst unsafe fnwill therefore fail the first time it is
ever used in a realconstcontext.
pointer::add/pointer::subare const-stable and avoid signed-offset
pitfalls.Suggested refactor (excerpt):
- let x = unsafe { **ptr }; - *ptr = unsafe { ptr.offset(1) }; + let x = unsafe { **ptr }; + *ptr = (*ptr).add(1); ... - let y = unsafe { **ptr }; - *ptr = unsafe { ptr.offset(1) }; + let y = unsafe { **ptr }; + *ptr = (*ptr).add(1); ... - *ptr = unsafe { ptr.offset(-1) }; + *ptr = (*ptr).sub(1);Apply the same pattern for every
offset(±1)occurrence in both forward and
reverse helpers.Also applies to: 274-309
vm/src/stdlib/posix.rs (1)
1231-1236: Remove const fn from sync() - external function calls are not allowed in const contexts.The
sync()function callslibc::sync(), which is an external C function that performs system calls with side effects. This cannot be evaluated at compile time and will cause compilation errors in const contexts.- const fn sync() { + fn sync() {common/src/linked_list.rs (1)
287-298: Remove const fn from drain_filter - closures are not supported in const contexts.The
drain_filtermethod takes a closure parameterF: FnMut(&mut T::Target) -> bool. Closures cannot be used in const fn contexts as they involve dynamic dispatch and mutable operations.- pub const fn drain_filter<F>(&mut self, filter: F) -> DrainFilter<'_, T, F> + pub fn drain_filter<F>(&mut self, filter: F) -> DrainFilter<'_, T, F>
🧹 Nitpick comments (3)
compiler/codegen/src/compile.rs (1)
4121-4123:set_source_rangeprobably shouldn’t beconstThis is a plain setter that mutates
self. Turning it intoconst fnbrings no practical benefit (it’s never called in aconstcontext) but does:
- Tie the crate to a relatively new rustc version (mutable
const fnstabilised only recently).- Risk future surprises if someone expects it to stay side-effect-free in const evaluation.
Unless you have a concrete need to call it inside a
constcontext, consider reverting theconstqualifier:- const fn set_source_range(&mut self, range: TextRange) { + fn set_source_range(&mut self, range: TextRange) {compiler/core/src/bytecode.rs (1)
175-180: Leaner bit-math alternative forinstr_sizeThe current chain of three comparisons works, but we can avoid the branchy logic by relying on
leading_zeros:- (self.0 > 0xff) as usize + (self.0 > 0xff_ff) as usize + (self.0 > 0xff_ff_ff) as usize + 1 + // #bytes = ceil(bits / 8) + ((32 - self.0.leading_zeros() + 7) / 8).max(1) as usizeBenefits: fewer comparisons, branch-free, and intention is clearer.
vm/sre_engine/src/engine.rs (1)
71-73: Const promotion approved; consider adding#[inline]The newly‐minted
const fns are simple accessors/mutators that stay within the stable const-eval rules, so the change is safe.For tiny hot-path helpers (
remaining_codes,remaining_chars,at_beginning,at_end, etc.) you may optionally add#[inline]to help LLVM inline them at call-sites (this is runtime only; has no impact on const contexts).Also applies to: 1057-1063, 1100-1116, 1147-1159, 1166-1179
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (66)
common/src/cformat.rs(1 hunks)common/src/encodings.rs(1 hunks)common/src/hash.rs(2 hunks)common/src/linked_list.rs(5 hunks)common/src/lock/thread_mutex.rs(1 hunks)compiler/codegen/src/compile.rs(2 hunks)compiler/codegen/src/string_parser.rs(1 hunks)compiler/codegen/src/symboltable.rs(1 hunks)compiler/codegen/src/unparse.rs(2 hunks)compiler/core/src/bytecode.rs(6 hunks)stdlib/src/array.rs(3 hunks)stdlib/src/binascii.rs(2 hunks)stdlib/src/compression.rs(5 hunks)stdlib/src/csv.rs(5 hunks)stdlib/src/faulthandler.rs(2 hunks)stdlib/src/hashlib.rs(3 hunks)stdlib/src/json/machinery.rs(1 hunks)stdlib/src/posixsubprocess.rs(2 hunks)stdlib/src/pystruct.rs(1 hunks)stdlib/src/select.rs(1 hunks)stdlib/src/syslog.rs(1 hunks)stdlib/src/unicodedata.rs(1 hunks)vm/src/buffer.rs(3 hunks)vm/src/builtins/asyncgenerator.rs(5 hunks)vm/src/builtins/builtin_func.rs(3 hunks)vm/src/builtins/bytearray.rs(1 hunks)vm/src/builtins/bytes.rs(1 hunks)vm/src/builtins/code.rs(4 hunks)vm/src/builtins/complex.rs(5 hunks)vm/src/builtins/coroutine.rs(3 hunks)vm/src/builtins/dict.rs(2 hunks)vm/src/builtins/enumerate.rs(1 hunks)vm/src/builtins/float.rs(1 hunks)vm/src/builtins/frame.rs(1 hunks)vm/src/builtins/function.rs(2 hunks)vm/src/builtins/iter.rs(2 hunks)vm/src/builtins/set.rs(1 hunks)vm/src/builtins/singletons.rs(2 hunks)vm/src/builtins/str.rs(4 hunks)vm/src/builtins/traceback.rs(2 hunks)vm/src/builtins/type.rs(2 hunks)vm/src/builtins/union.rs(1 hunks)vm/src/codecs.rs(1 hunks)vm/src/function/protocol.rs(1 hunks)vm/src/intern.rs(2 hunks)vm/src/object/core.rs(6 hunks)vm/src/object/ext.rs(2 hunks)vm/src/protocol/iter.rs(1 hunks)vm/src/protocol/sequence.rs(1 hunks)vm/src/readline.rs(1 hunks)vm/src/sliceable.rs(2 hunks)vm/src/stdlib/ast.rs(3 hunks)vm/src/stdlib/collections.rs(1 hunks)vm/src/stdlib/imp.rs(2 hunks)vm/src/stdlib/io.rs(6 hunks)vm/src/stdlib/os.rs(4 hunks)vm/src/stdlib/posix.rs(3 hunks)vm/src/stdlib/sre.rs(1 hunks)vm/src/stdlib/stat.rs(1 hunks)vm/src/stdlib/symtable.rs(4 hunks)vm/src/stdlib/sys.rs(5 hunks)vm/src/stdlib/typevar.rs(3 hunks)vm/src/stdlib/typing.rs(1 hunks)vm/src/types/slot.rs(4 hunks)vm/sre_engine/src/engine.rs(5 hunks)vm/sre_engine/src/string.rs(4 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.rs`: Follow the default rustfmt code style (`cargo fmt` to format) Always ...
**/*.rs: Follow the default rustfmt code style (cargo fmtto format)
Always run clippy to lint code (cargo clippy) before completing tasks. Fix any warnings or lints that are introduced by your changes
Follow Rust best practices for error handling and memory management
Use the macro system (pyclass,pymodule,pyfunction, etc.) when implementing Python functionality in Rust
📄 Source: CodeRabbit Inference Engine (.github/copilot-instructions.md)
List of files the instruction was applied to:
vm/src/builtins/frame.rsstdlib/src/pystruct.rscommon/src/lock/thread_mutex.rsvm/src/protocol/iter.rsstdlib/src/unicodedata.rsstdlib/src/json/machinery.rsvm/src/readline.rsstdlib/src/syslog.rsvm/src/function/protocol.rsvm/src/builtins/bytearray.rsvm/src/builtins/singletons.rsvm/src/builtins/set.rscommon/src/hash.rscompiler/codegen/src/string_parser.rsvm/src/stdlib/collections.rsvm/src/stdlib/sre.rsvm/src/protocol/sequence.rsstdlib/src/select.rsvm/src/builtins/float.rsvm/src/object/ext.rsvm/src/builtins/union.rsvm/src/stdlib/typing.rscommon/src/cformat.rsstdlib/src/posixsubprocess.rsvm/src/builtins/bytes.rscommon/src/encodings.rsvm/src/builtins/coroutine.rsvm/src/buffer.rsvm/src/sliceable.rsvm/src/builtins/iter.rscompiler/codegen/src/symboltable.rsstdlib/src/faulthandler.rsvm/src/builtins/traceback.rsstdlib/src/binascii.rscompiler/codegen/src/unparse.rscompiler/codegen/src/compile.rsvm/src/builtins/builtin_func.rsvm/src/stdlib/symtable.rsvm/src/stdlib/ast.rsvm/src/builtins/function.rsvm/src/builtins/type.rsvm/src/builtins/dict.rsvm/sre_engine/src/string.rsvm/src/intern.rsvm/src/types/slot.rsvm/src/builtins/code.rsvm/src/stdlib/imp.rsstdlib/src/hashlib.rsvm/src/codecs.rsvm/src/builtins/complex.rsvm/src/builtins/str.rsvm/src/stdlib/os.rsvm/src/stdlib/sys.rsstdlib/src/csv.rsstdlib/src/compression.rsvm/src/builtins/asyncgenerator.rsvm/src/stdlib/typevar.rscommon/src/linked_list.rsstdlib/src/array.rsvm/src/object/core.rscompiler/core/src/bytecode.rsvm/src/builtins/enumerate.rsvm/sre_engine/src/engine.rsvm/src/stdlib/io.rsvm/src/stdlib/stat.rsvm/src/stdlib/posix.rs
🧠 Learnings (28)
stdlib/src/pystruct.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
stdlib/src/syslog.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/builtins/singletons.rs (2)
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
stdlib/src/select.rs (2)
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
vm/src/builtins/float.rs (2)
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
vm/src/object/ext.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
stdlib/src/posixsubprocess.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Follow Rust best practices for error handling and memory management
vm/src/builtins/coroutine.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/buffer.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Follow the default rustfmt code style (`cargo fmt` to format)
stdlib/src/faulthandler.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/builtins/builtin_func.rs (3)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
vm/src/stdlib/symtable.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/stdlib/ast.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/builtins/function.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/builtins/type.rs (3)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
vm/src/builtins/dict.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/sre_engine/src/string.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Follow Rust best practices for error handling and memory management
vm/src/types/slot.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/builtins/code.rs (2)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: In most cases, Python code should not be edited. Bug fixes should be made through Rust code modifications only
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/stdlib/imp.rs (3)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
vm/src/builtins/complex.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/builtins/str.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/stdlib/os.rs (2)
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
vm/src/stdlib/sys.rs (3)
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/builtins/asyncgenerator.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/object/core.rs (1)
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/stdlib/stat.rs (3)
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
vm/src/stdlib/posix.rs (3)
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration using #ifdef checks rather than providing fallback values for other platforms.
Learnt from: moreal
PR: RustPython/RustPython#5847
File: vm/src/stdlib/stat.rs:547-567
Timestamp: 2025-06-27T14:47:28.810Z
Learning: In RustPython's stat module implementation, platform-specific constants like SF_SUPPORTED and SF_SYNTHETIC should be conditionally declared only for the platforms where they're available (e.g., macOS), following CPython's approach of optional declaration rather than providing fallback values for other platforms.
Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T10:08:48.851Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust
🧬 Code Graph Analysis (15)
stdlib/src/json/machinery.rs (4)
vm/src/bytes_inner.rs (1)
len(308-310)common/src/boxvec.rs (1)
len(49-51)common/src/str.rs (1)
len(292-294)wtf8/src/lib.rs (1)
len(785-787)
vm/src/builtins/singletons.rs (2)
vm/src/builtins/float.rs (1)
__bool__(288-290)vm/src/builtins/tuple.rs (1)
__bool__(254-256)
vm/src/builtins/float.rs (2)
vm/src/builtins/complex.rs (1)
__abs__(260-269)vm/src/builtins/int.rs (1)
__abs__(490-492)
stdlib/src/posixsubprocess.rs (4)
stdlib/src/syslog.rs (1)
as_ptr(50-55)common/src/boxvec.rs (1)
as_ptr(326-328)stdlib/src/ssl.rs (1)
as_ptr(1559-1561)extra_tests/snippets/stdlib_ctypes.py (1)
c_char(175-176)
vm/src/builtins/bytes.rs (7)
vm/src/builtins/bytearray.rs (1)
__len__(209-211)vm/src/builtins/dict.rs (3)
__len__(207-209)__len__(759-761)is_empty(112-114)vm/src/builtins/set.rs (2)
__len__(550-552)__len__(976-978)vm/src/builtins/list.rs (1)
__len__(184-186)vm/src/builtins/mappingproxy.rs (1)
__len__(183-186)vm/src/builtins/tuple.rs (3)
__len__(271-273)is_empty(276-278)is_empty(558-560)vm/src/builtins/str.rs (8)
is_empty(592-594)is_empty(1468-1470)is_empty(1862-1864)is_empty(1872-1874)is_empty(1882-1884)is_empty(1939-1941)is_empty(2054-2056)is_empty(2176-2178)
vm/src/builtins/coroutine.rs (3)
vm/src/builtins/asyncgenerator.rs (3)
as_coro(32-34)r#await(204-206)r#await(298-300)vm/src/builtins/generator.rs (1)
as_coro(31-33)wasm/lib/src/js_module.rs (1)
r#await(545-549)
vm/src/buffer.rs (3)
vm/src/builtins/range.rs (1)
offset(80-89)stdlib/src/pystruct.rs (1)
size(262-264)vm/src/builtins/dict.rs (1)
size(158-160)
compiler/codegen/src/symboltable.rs (1)
vm/src/stdlib/symtable.rs (2)
is_global(173-175)is_local(183-185)
compiler/codegen/src/compile.rs (4)
compiler/codegen/src/string_parser.rs (1)
new(31-37)compiler/codegen/src/unparse.rs (1)
new(35-37)compiler/core/src/bytecode.rs (2)
new(287-289)new(663-665)vm/src/stdlib/typing.rs (1)
new(108-118)
vm/src/stdlib/symtable.rs (1)
compiler/codegen/src/symboltable.rs (2)
is_global(165-170)is_local(172-174)
vm/src/builtins/function.rs (6)
vm/src/builtins/code.rs (1)
new(205-207)vm/src/builtins/dict.rs (2)
new(695-697)new(726-728)vm/src/stdlib/io.rs (1)
new(255-257)vm/src/types/slot.rs (1)
new(99-105)vm/src/frame.rs (1)
new(138-172)vm/src/builtins/module.rs (1)
new(72-77)
vm/sre_engine/src/string.rs (1)
wtf8/src/core_str.rs (2)
next_code_point(33-67)next_code_point_reverse(76-110)
vm/src/builtins/complex.rs (2)
vm/src/builtins/float.rs (4)
real(465-467)imag(470-472)__pos__(343-345)__getnewargs__(514-516)vm/src/builtins/int.rs (4)
real(669-671)imag(674-676)__pos__(538-540)__getnewargs__(696-698)
vm/src/builtins/str.rs (2)
common/src/str.rs (4)
as_wtf8(257-259)kind(274-276)is_utf8(43-45)is_ascii(39-41)wtf8/src/lib.rs (5)
as_wtf8(1349-1351)as_bytes(827-829)is_utf8(983-985)is_ascii(175-177)is_ascii(978-980)
stdlib/src/compression.rs (6)
stdlib/src/unicodedata.rs (1)
new(86-88)stdlib/src/zlib.rs (8)
new(121-134)new(419-421)new(476-485)eof(231-233)eof(595-597)unused_data(236-238)unused_data(600-602)needs_input(605-607)stdlib/src/lzma.rs (4)
new(262-264)eof(193-195)unused_data(198-200)needs_input(203-207)common/src/boxvec.rs (2)
len(49-51)is_empty(54-56)wtf8/src/lib.rs (2)
len(785-787)is_empty(790-792)stdlib/src/bz2.rs (3)
eof(90-92)unused_data(95-97)needs_input(100-104)
⏰ Context from checks skipped due to timeout of 90000ms (7)
- GitHub Check: Run snippets and cpython tests on wasm-wasi
- GitHub Check: Check the WASM package and demo
- GitHub Check: Run snippets and cpython tests (windows-latest)
- GitHub Check: Run tests under miri
- GitHub Check: Run rust tests (windows-latest)
- GitHub Check: Check Rust code with rustfmt and clippy
- GitHub Check: Ensure compilation on various targets
🔇 Additional comments (149)
vm/src/builtins/frame.rs (1)
37-39: LGTM: const fn qualification is technically correct.The const fn qualifier is valid since this is currently a placeholder method. However, note that when the actual implementation replaces the TODO comment, you'll need to verify that the operations performed are compatible with const fn restrictions.
stdlib/src/pystruct.rs (1)
318-318: LGTM: Empty function correctly qualified as const fn.The const fn qualifier is appropriate for this empty function, enabling compile-time evaluation when called.
stdlib/src/select.rs (1)
27-29: LGTM: Excellent const fn usage for compile-time evaluation.The const fn qualifier is perfect for this simple comparison operation, enabling compile-time error checking when the input value is known at compile time.
common/src/lock/thread_mutex.rs (1)
81-86: LGTM: Excellent const fn usage enabling static initialization.The const fn qualifier is perfectly appropriate here since both
RawThreadMutex::INITandUnsafeCell::neware const. This enables static initialization ofThreadMutexinstances, which is particularly valuable for synchronization primitives.vm/src/readline.rs (1)
31-33: LGTM: Simple constructor correctly qualified as const fn.The const fn qualifier is appropriate for this simple struct constructor, enabling compile-time initialization of
Readlineinstances when the helper parameter supports const construction.vm/src/builtins/bytearray.rs (1)
80-80: LGTM: Appropriate const fn conversion.The
from_innerfunction is a simple constructor that only initializes struct fields with basic operations, making it suitable for const evaluation.stdlib/src/syslog.rs (2)
138-140: LGTM: Appropriate const fn conversion.The
log_maskfunction performs a simple bit shift operation which is const-eligible.
144-146: LGTM: Appropriate const fn conversion.The
log_uptofunction performs simple arithmetic operations on primitive integers, making it suitable for const evaluation.stdlib/src/json/machinery.rs (1)
122-128: LGTM: Appropriate const fn conversion.The
lenmethod performs pattern matching and calls to const functions (Wtf8::lenandCodePoint::len_wtf8), making it suitable for const evaluation.vm/src/stdlib/collections.rs (1)
276-278: LGTM: Perfect const fn candidate.The
maxlengetter is a simple field access operation, which is ideal for const evaluation.stdlib/src/binascii.rs (2)
163-170: LGTM: Appropriate const fn conversion.The
unhex_nibblefunction performs pattern matching and simple arithmetic on primitive types, making it suitable for const evaluation.
813-819: LGTM: Appropriate const fn conversion.The
uu_b2afunction performs simple conditional logic and arithmetic on primitive types, making it suitable for const evaluation.stdlib/src/unicodedata.rs (1)
86-88: LGTM! Appropriate const fn conversion.This simple constructor is an ideal candidate for
const fnas it performs only struct field assignment without side effects, enabling compile-time evaluation.vm/src/object/ext.rs (2)
69-71: LGTM! Valid const unsafe fn conversion.The pointer cast operation in this function is valid in const contexts and enables compile-time evaluation of this unsafe operation.
144-146: LGTM! Appropriate const unsafe fn conversion.This simple struct wrapper construction is suitable for const contexts and aligns with the PR's goal of enabling compile-time evaluation where possible.
vm/src/stdlib/typing.rs (1)
108-118: LGTM! Excellent const fn candidate.This constructor performs only simple field assignments without side effects, making it an ideal candidate for
const fnand enabling compile-time instantiation ofTypeAliasType.stdlib/src/faulthandler.rs (2)
42-44: LGTM! Valid const fn for unimplemented function.Since this function is currently unimplemented (TODO), marking it as
const fnis valid and prepares it for potential const implementation in the future.
60-62: LGTM! Appropriate const fn for placeholder function.The const qualification is valid for this unimplemented function and aligns with the systematic const fn updates across the codebase.
common/src/hash.rs (2)
167-175: LGTM! Perfect const fn candidate.This function performs only a simple type cast operation, making it an excellent candidate for
const fnand enabling compile-time hash calculations.
178-180: LGTM! Proper const fn composition.This function correctly composes two const functions (
hash_object_id_rawandfix_sentinel), making it appropriately qualified asconst fn.vm/src/builtins/set.rs (1)
457-459: LGTM! Appropriate const fn conversion.The bitwise operations (XOR, shift, wrapping multiplication) are all const-compatible, making this function suitable for compile-time evaluation.
common/src/encodings.rs (1)
140-152: LGTM! Appropriate const unsafe fn conversion.The unsafe operations (
split_at_uncheckedandfrom_utf8_unchecked) are const-compatible, and the function logic is suitable for compile-time evaluation.vm/src/stdlib/ast.rs (3)
93-98: LGTM! Appropriate const fn conversion.Simple struct construction with field access is const-compatible.
106-108: LGTM! Appropriate const fn conversion.Field access via method call is const-compatible.
120-126: LGTM! Appropriate const fn conversions.Both functions perform simple field access and transformations that are const-compatible.
stdlib/src/hashlib.rs (3)
193-195: LGTM! Appropriate const fn conversion.Returning a constant value is perfectly suitable for const fn.
320-322: LGTM! Appropriate const fn conversion.Pattern matching with
matches!macro is const-compatible.
384-386: LGTM! Appropriate const fn conversion.Simple field access is const-compatible.
vm/src/stdlib/imp.rs (2)
38-44: LGTM! Appropriate const fn conversions.No-op functions and constant returns are perfectly suitable for const fn when threading is disabled.
98-100: LGTM! Appropriate const fn conversion.Creating an empty vector and wrapping it in
Okis const-compatible.vm/src/stdlib/os.rs (4)
88-88: LGTM: Appropriate const fn conversion.Converting
fd()toconst fnis correct since it only performs a simple field access (self.0[0]), enabling compile-time evaluation.
574-574: LGTM: Appropriate const fn conversion.Converting
is_junction() toconst fnis correct for the non-Windows implementation since it only returns a constantOk(false), enabling compile-time evaluation.
645-645: LGTM: Appropriate const fn conversion.Converting
__enter__()toconst fnis correct since it only returns the input parameterzelf, which is a simple operation suitable for compile-time evaluation.
1498-1498: LGTM: Appropriate const fn conversion.Converting
SupportFunc::new()toconst fnis correct since it's a simple constructor that only assigns parameters to struct fields, enabling compile-time instantiation.vm/src/stdlib/sys.rs (5)
98-98: LGTM: Appropriate const fn conversion.Converting
default_prefix()toconst fnis correct since it only returns string literals based on compile-timecfg!()conditions, enabling compile-time evaluation.
241-241: LGTM: Appropriate const fn conversion.Converting
meta_path()toconst fnis correct since it only returnsVec::new(), which is const-compatible and enables compile-time evaluation.
261-261: LGTM: Appropriate const fn conversion.Converting
path_hooks()toconst fnis correct since it only returnsVec::new(), which is const-compatible and enables compile-time evaluation.
457-457: LGTM: Appropriate const fn conversion.Converting
getdefaultencoding()toconst fnis correct since it only returns a constant referencecrate::codecs::DEFAULT_ENCODING, enabling compile-time evaluation.
967-967: LGTM: Appropriate const fn conversion.Converting
Flags::from_settings()toconst fnis correct since it only performs simple field assignments and type conversions (boolean to u8 casts) that are const-compatible, enabling compile-time struct creation.stdlib/src/array.rs (3)
92-96: LGTM: Appropriate const fn conversions for metadata accessors.These methods perform simple pattern matching on enum variants and return compile-time constants, making them ideal candidates for
const fn. This enables their use in constant contexts without changing runtime behavior.Also applies to: 98-102, 104-109, 111-115
557-559: LGTM: Correct const fn conversion for byte-swapping utilities.The bit manipulation operations
f32::to_bits(),u32::swap_bytes(), andf32::from_bits()are all const methods, making these functions suitable for compile-time evaluation.Also applies to: 561-563
1560-1567: LGTM: Appropriate const fn for machine format code size calculation.This method uses simple pattern matching to return compile-time constants, making it a good candidate for
const fnevaluation.vm/src/stdlib/typevar.rs (3)
127-129: LGTM: Appropriate const fn conversion for boolean field accessors.These getter methods perform simple field access to return boolean values, making them perfect candidates for
const fnevaluation.Also applies to: 132-134, 137-139
448-450: LGTM: Consistent const fn conversion for ParamSpec boolean accessors.These methods mirror the TypeVar implementations and are also simple field accessors, appropriately converted to
const fn.Also applies to: 453-455, 458-460
630-640: LGTM: Appropriate const fn conversion for ParamSpec constructor.This constructor initializes a struct with the provided name and const default values (
None,false), making it suitable for compile-time evaluation when called with const arguments.stdlib/src/csv.rs (3)
87-89: LGTM: Simple field getters are perfect candidates for const fn.These getter methods only perform direct field access, making them ideal for compile-time evaluation.
Also applies to: 91-93, 111-113
919-921: LGTM: Field access getters are ideal for const fn.These methods simply return struct fields, making them perfect candidates for compile-time evaluation.
Also applies to: 1069-1071
662-689: Const fn compatibility verifiedThe
check_and_fill!macro expands to simple field assignments and theif letbranches only perform pattern matching and assignments—no function calls or unsupported operations. All constructs (if,if let, local mutations) are supported in aconst fnon stable Rust. No changes needed.stdlib/src/compression.rs (4)
69-71: LGTM: Generic function returning const associated item.The
flush_syncfunction returnsT::SYNCwhich is a const associated item, making this conversion appropriate for compile-time evaluation.
79-84: LGTM: Constructor patterns are ideal for const fn.Both
newandchainconstructors perform simple field initialization and conditional logic without any heap allocations or complex operations, making them perfect for const evaluation.Also applies to: 85-94
95-97: LGTM: Simple arithmetic and slice operations are const-compatible.The
lenmethod performs arithmetic on field lengths, andis_emptycalls the constis_empty()method on slices. Both are appropriate for const fn.Also applies to: 98-100
219-223: LGTM: Constructor and simple field getters.These methods involve either simple field initialization (
new) or direct field access (eof,needs_input), all of which are const-eligible operations.Also applies to: 296-298, 304-306
vm/src/stdlib/stat.rs (4)
249-251: LGTM: Bitwise operations are perfect for const fn.These file type checking functions perform simple bitwise AND operations and equality comparisons, making them ideal candidates for compile-time evaluation.
Also applies to: 255-257, 261-263, 267-269, 273-275, 279-281, 285-287
292-294: LGTM: Platform-specific functions with const return values.These functions return constant
falsevalues for unsupported platforms (Solaris, BSD), which is appropriate for const fn since they involve no runtime computation.Also applies to: 299-301, 306-308
312-314: LGTM: Simple bitwise mask operations.Both
S_IMODE_methodandS_IFMT_methodperform straightforward bitwise AND operations with constant masks, making them excellent candidates for const fn.Also applies to: 318-321
324-348: LGTM: Conditional logic calling other const functions.The
filetypefunction uses conditional logic that calls other const functions (the S_IS* family) and returns character literals. Since all called functions are now const fn and the logic involves only compile-time determinable operations, this conversion is appropriate.vm/src/protocol/iter.rs (1)
36-38: LGTM: Simple constructor ideal for const fn.The
newmethod is a straightforward constructor that wraps the input in a tuple struct. This pattern is perfect for const fn as it involves only field initialization without any heap allocation or complex operations.vm/src/stdlib/sre.rs (1)
399-401: LGTM: Bitflags accessor method is const-compatible.The
flagsmethod callsbits()on aSreFlagfield. SinceSreFlagappears to be a bitflags type and bitflags typically provide constbits()methods, this conversion is appropriate for enabling compile-time evaluation.vm/src/builtins/float.rs (1)
234-236: LGTM: Valid const function conversion.The
__abs__method correctly usesconst fnsince it only callsself.value.abs()on an f64, which is const-compatible. This change enables compile-time evaluation without altering the method's behavior.vm/src/codecs.rs (1)
55-57: LGTM: Valid const function conversion.The
as_tuplemethod correctly usesconst fnsince it only returns a reference to an inner field (&self.0). This is a simple accessor that can be evaluated at compile time.vm/src/builtins/union.rs (1)
45-47: LGTM: Valid const function conversion.The
argsmethod correctly usesconst fnsince it only returns a reference to theargsfield (&self.args). This simple accessor method can be evaluated at compile time while maintaining compatibility with CPython's_Py_union_args.common/src/cformat.rs (1)
139-148: LGTM: Valid const function conversion.The
sign_stringmethod correctly usesconst fnsince it only performs const-compatible operations:contains()calls on bitflags and returns static string literals. The conditional logic can be evaluated at compile time.vm/src/protocol/sequence.rs (1)
79-81: LGTM! Appropriate const fn conversion.This constructor only performs struct literal construction with reference parameters, making it an ideal candidate for
const fn. The change enables compile-time evaluation without altering runtime behavior.vm/src/builtins/singletons.rs (2)
49-51: LGTM! Correct const fn usage for constant return value.The
__bool__method returns a compile-time constant (false), making it an appropriate candidate forconst fn. This aligns with similar implementations in other builtin types.
101-103: LGTM! Correct const fn usage for constant return value.The
__bool__method returns a compile-time constant (true), making it an appropriate candidate forconst fn. This follows the same pattern as thePyNoneimplementation.vm/src/builtins/enumerate.rs (1)
104-109: LGTM! Appropriate const fn conversion for constructor.The constructor performs only const-safe operations: arithmetic (
saturating_sub) and struct construction. This change is consistent with the systematic const fn updates across the codebase.vm/src/builtins/bytes.rs (2)
152-154: LGTM! Consistent const fn pattern for length accessor.The
__len__method delegates to the inner type's length method, following the same pattern established in other collection types as shown in the relevant code snippets (PyTuple,PyDict, etc.).
157-159: LGTM! Consistent const fn pattern for emptiness check.The
is_emptymethod delegates to the inner type's emptiness check, maintaining consistency with similar implementations across other collection types in the codebase.stdlib/src/posixsubprocess.rs (2)
119-121: LGTM! Appropriate const fn for pointer accessor.The
as_ptrmethod delegates to the standard library'sslice.as_ptr(), which is const-safe. This follows the pattern seen in other pointer accessor methods across the codebase.
177-183: LGTM! Perfect const fn candidate for string literals.The
as_msgmethod performs simple pattern matching returning compile-time string literals, making it an ideal candidate forconst fnwith no runtime dependencies or side effects.vm/src/function/protocol.rs (1)
133-135: LGTM - Validconst fnconversionThis constructor function correctly converts to
const fnsince it only performs simple struct field assignment. This enables compile-time evaluation ofArgMappinginstances when the arguments are known at compile time.vm/src/builtins/iter.rs (2)
50-55: LGTM - Validconst fnconversion forPositionIterInternalThis constructor correctly converts to
const fnsince it only performs enum construction and field assignment. This enables compile-time instantiation ofPositionIterInternalinstances.
259-264: LGTM - Validconst fnconversion forPyCallableIteratorThis constructor correctly converts to
const fn. The use ofPyRwLock::newis appropriate since it's typically implemented as aconst fnin standard library implementations.compiler/codegen/src/string_parser.rs (1)
31-37: Verifyconst fncompatibility withBox<str>inStringParser::new(compiler/codegen/src/string_parser.rs:31–37)We weren’t able to run a full
cargo checkin the sandbox due to toolchain errors. Before merging, please:
- Manually confirm that
StringParser::new(source: Box<str>, flags: AnyStringFlags) -> Selfcompiles on stable Rust (≥1.88) without errors.- Ensure you can call it in a const context (e.g. define
const PARSER: StringParser = StringParser::new(...);) and that the compiler accepts theBox<str>parameter in const evaluation.- If Box-based parameters don’t work in const fn due to allocation or Drop constraints, revert this change or document the limitation clearly.
compiler/codegen/src/compile.rs (1)
285-292:PatternContext::newsafely promoted toconst fn– looks good
Vec::new()and the other operations used here are allconst-stable on the MSRV you’re already targeting, so this change compiles on stable and widens the function’s usability without side-effects.vm/src/sliceable.rs (1)
418-425: LGTM! Appropriate use ofconst fnBoth
from_adjust_indicesandpositive_ordermethods are good candidates forconst fnas they only perform simple arithmetic operations and conditional logic that are available in constant evaluation contexts. The use ofis_negative(),saturating_sub(), andsaturating_abs()are all const-compatible operations.Also applies to: 427-433
vm/src/builtins/function.rs (2)
725-727: LGTM! Simple constructor perfect forconst fnThis constructor only performs struct field initialization, making it an ideal candidate for
const fn. This change aligns with the pattern observed in other constructor methods across the codebase.
849-853: LGTM! Constructor appropriately marked asconst fnThe
PyCell::newconstructor only creates a struct with aPyMutex, which should be const-compatible. This change is consistent with similar constructor patterns in the codebase.vm/src/buffer.rs (3)
204-210: LGTM! Appropriateconst fnfor simple pattern matchingThe
arg_countmethod only performs pattern matching on an enum and returns either constants or field values, making it an excellent candidate forconst fn.
289-297: LGTM! Alignment calculation function suitable forconst fnThe
compensate_alignmentfunction uses only const-compatible operations including arithmetic, bit operations, andchecked_sub. The logic is purely computational without side effects, making it appropriate for compile-time evaluation.
447-449: LGTM! Simple getter perfect forconst fnThis is a straightforward field accessor that returns the
sizefield, making it an ideal candidate forconst fn. This pattern is consistent with similar const getters found instdlib/src/pystruct.rsline 262-264.compiler/codegen/src/symboltable.rs (3)
165-170: LGTM! Appropriate const fn conversion.The
is_globalmethod uses only const-compatible operations (matches!macro with enum pattern matching) and has no side effects, making it a good candidate forconst fn.
172-174: LGTM! Appropriate const fn conversion.The
is_localmethod uses only const-compatible operations and is a pure function, making it suitable forconst fn.
176-178: LGTM! Appropriate const fn conversion.The
is_boundmethod usesintersectson bitflags which is const-compatible, and this change enables the method to be used in the const contexts shown in the relevant snippets.compiler/codegen/src/unparse.rs (2)
35-37: LGTM! Appropriate const fn conversion.The
newconstructor performs only simple field assignments, making it a perfect candidate forconst fn. This enables compile-time construction ofUnparserinstances.
605-607: LGTM! Appropriate const fn conversion.The
unparse_exprfunction is a simple constructor that creates a struct with two fields, making it suitable forconst fnand enabling compile-time creation ofUnparseExprinstances.vm/src/builtins/traceback.rs (3)
50-52: LGTM! Appropriate const fn conversion.Simple field getter that returns a primitive value, perfect for
const fn.
55-57: Verify thatLineNumber::get()is aconst fn.I wasn’t able to locate the implementation of
LineNumber::getin the VM codebase (it may live in an external crate). Please confirm that its definition is declared as:impl LineNumber { pub const fn get(&self) -> usize { … } }so that calling
self.lineno.get()inside aconst fn tb_lineno()remains valid.
30-42: Confirm thatPyMutex::newis aconst fn.The
const fn newonPyTracebackhinges onPyMutex::newbeingconst. Sincepub type PyMutex<T> = Mutex<RawMutex, T>;is just an alias for
lock_api::Mutex<RawMutex, T>, please verify that in yourlock_apiversion
Mutex::new(...)is indeed declared asconst fn. If it isn’t, you’ll need to either:
- Upgrade to a
lock_apirelease whereMutex::newisconst fn.- Or provide a small
const fnwrapper/alias incommon/src/lock.rs(e.g.,const fn new_mutex<T>(t: T) -> PyMutex<T> { Mutex::new(t) }).vm/src/intern.rs (2)
121-123: LGTM! Appropriate const fn conversion.The
unsafetransmute_copyoperation is const-compatible and this method is a good candidate forconst fn. The safety requirements remain the same in const contexts.
145-147: LGTM! Appropriate const fn conversion.Pointer casting operations are const-compatible, making this method suitable for
const fn. This enables compile-time pointer address calculations.vm/src/builtins/type.rs (3)
76-78: Appropriate conversion toconst unsafe fn.This unsafe function is pure and performs only a simple reference conversion, making it suitable for compile-time evaluation.
624-626: Good conversion toconst fnfor getter method.This simple getter method returns a field value without side effects, making it appropriate for compile-time evaluation.
629-631: Good conversion toconst fnfor getter method.This simple getter method returns a field value without side effects, making it appropriate for compile-time evaluation.
vm/src/builtins/builtin_func.rs (3)
39-42: Appropriate conversion toconst fnfor builder method.This method performs a simple field modification and return, making it suitable for compile-time evaluation.
53-58: Good conversion toconst fnfor conditional getter.This method performs simple flag checking and returns a reference conditionally, which is appropriate for compile-time evaluation.
122-125: Appropriate conversion toconst fnfor simple getter.This method returns a static string field without side effects, making it suitable for compile-time evaluation.
vm/src/stdlib/symtable.rs (4)
32-34: Appropriate conversion toconst fnfor constructor.This simple wrapper constructor performs no side effects and is suitable for compile-time evaluation.
173-175: Good conversion toconst fnfor predicate method.This method calls
self.symbol.is_global()(which isconst fnbased on the relevant code snippet fromcompiler/codegen/src/symboltable.rs) and performs boolean logic, making it appropriate for compile-time evaluation.
183-185: Good conversion toconst fnfor predicate method.This method calls
self.symbol.is_local() (which is const fnbased on the relevant code snippet fromcompiler/codegen/src/symboltable.rs) and performs boolean logic, making it appropriate for compile-time evaluation.
193-196: Appropriate conversion toconst fnfor trivial function.This method simply returns a constant value, making it clearly suitable for compile-time evaluation.
vm/src/builtins/dict.rs (2)
60-62: LGTM: Appropriate const fn usage for simple accessor.This method simply returns a reference to an internal field, making it an ideal candidate for
const fn. The change enables compile-time evaluation without altering the method's behavior.
379-391: LGTM: Consistent const fn application for view constructors.These methods create dictionary view objects using simple constructors. The
const fnqualifier is appropriate here since the constructors (as seen in the macro expansion at line 779) are also const-compatible, enabling compile-time evaluation of these view creations.vm/src/builtins/coroutine.rs (3)
28-30: LGTM: Consistent const fn pattern across coroutine types.This accessor method returns a reference to the internal
Corofield, which is appropriate forconst fn. The change aligns with identical patterns ingenerator.rsandasyncgenerator.rs(as shown in relevant snippets), maintaining consistency across coroutine-related types.
49-51: LGTM: Appropriate const fn for simple struct construction.This method creates a
PyCoroutineWrapperthrough simple struct construction, making it suitable forconst fn. The pattern aligns with similar async implementations in the codebase while enabling compile-time evaluation.
72-74: LGTM: Const fn appropriate for constant return value.This placeholder method always returns
None, making it an ideal candidate forconst fn. The unused_vmparameter doesn't prevent const evaluation since the method body only returns a compile-time constant.vm/src/builtins/str.rs (3)
416-424: Accessor safely promoted toconst fn– looks goodThe new
constqualifier onas_wtf8/as_bytesis correct:
• both simply delegate to already-consthelpers onStrData/Wtf8;
• no proc-macro attributes are attached, so nothing blocks compile-time evaluation.No further action required.
459-471:kind()/is_utf8()nowconst– LGTMThese trivial getters don’t rely on anything non-const and will be usable in
constcontexts immediately.
604-606: Verify#[pymethod] const fnmacro expansionThe sandbox build failed due to a missing C linker (
cc not found), so we couldn’t confirm that the#[pymethod]proc-macro still handlesconst fn. Please verify on your local machine:
- Install a C linker (e.g.
gcc/build-essential).- Run
cargo checkorcargo testto ensure the build succeeds.- Optionally use
cargo expandon theis_asciimethod invm/src/builtins/str.rs(lines 604–606) to inspect the generated binding named"isascii".vm/sre_engine/src/string.rs (1)
370-373: Constifying simple predicates is fine
is_linebreak/is_uni_linebreakare pure value checks; marking themconst
poses no problems.Also applies to: 436-441
vm/src/builtins/code.rs (2)
205-208: Constructor can safely beconst
PyCode::newis a plain struct literal – upgrading toconstis harmless and
useful for embedding byte‐code blobs in futureconstcontexts.
245-258: Const getters with#[pygetset]are supported
Inspected thepygetsetprocedural macro (in derive/src/lib.rs → derive-impl) and confirmed it forwards the complete function signature (includingconst) via#sig. There’s no special pattern-match excludingconst fn, so your const-qualified getters will be preserved correctly. No changes required.vm/src/types/slot.rs (5)
152-154: LGTM: Appropriate const fn conversionThe
has_featuremethod only performs bitwise operations viacontains(), making it suitable forconst fn.
157-159: LGTM: Appropriate const fn conversionThe
is_created_with_flagsmethod only performs bitwise flag checking, making it suitable forconst fn.
328-330: LGTM: Appropriate const fn conversionThe
self_iterfunction only returns its parameter wrapped inOk(), making it suitable forconst fn.
1112-1119: LGTM: Appropriate const fn conversionThe
eval_ordmethod only performs pattern matching and bitwise operations, making it suitable forconst fn.
1121-1130: LGTM: Appropriate const fn conversionThe
swappedmethod only performs pattern matching and returns enum variants, making it suitable forconst fn.vm/src/builtins/complex.rs (6)
31-33: LGTM: Appropriate const fn conversionThe
to_complex64method only returns a field value, making it suitable forconst fn.
239-241: LGTM: Appropriate const fn conversionThe
to_complexmethod only returns a field value, making it suitable forconst fn.
250-252: LGTM: Appropriate const fn conversionThe
realgetter only returns a field from the complex value, making it suitable forconst fn.
255-257: LGTM: Appropriate const fn conversionThe
imaggetter only returns a field from the complex value, making it suitable forconst fn.
349-351: LGTM: Appropriate const fn conversionThe
__pos__method only returns the complex value, making it suitable forconst fn.
387-390: LGTM: Appropriate const fn conversionThe
__getnewargs__method only destructures the complex value and returns a tuple of primitives, making it suitable forconst fn. Note that this differs from the float/int implementations which take a VM parameter, but this implementation is simpler and can be const.vm/src/object/core.rs (6)
424-428: LGTM: Appropriate const fn conversionThe
InstanceDict::newmethod only wraps the parameter in aPyRwLock::new(), which is const in Rust standard library.
515-519: LGTM: Appropriate const fn conversionThe
into_rawmethod only extracts the pointer and forgets self, which are compile-time operations suitable forconst fn.
527-529: LGTM: Appropriate const unsafe fn conversionThe
from_rawmethod only creates a struct from a raw pointer, which is a compile-time operation suitable forconst unsafe fn.
666-671: LGTM: Appropriate const unsafe fn conversionThe
payload_uncheckedmethod only performs pointer casting operations, which are compile-time operations suitable forconst unsafe fn.
1029-1033: LGTM: Appropriate const unsafe fn conversionThe
from_rawmethod only creates a struct from a raw pointer usingNonNull::new_unchecked, which are compile-time operations suitable forconst unsafe fn.
1053-1057: LGTM: Appropriate const fn conversionThe
leakmethod only extracts the pointer and forgets the object, which are compile-time operations suitable forconst fn.vm/src/stdlib/posix.rs (2)
214-220: LGTM: Simple bitwise operations are appropriate for const fn.This function only performs bitwise operations on primitive types, which is well-suited for compile-time evaluation.
1606-1633: Verify const-evaluability of libc macrosThe CI environment couldn’t complete the Rust compilation test, so you’ll need to manually confirm that these wrappers actually compile as
const fnon your supported targets. If any of the following macros aren’t const-evaluable, you’ll need to remove theconstqualifier or gate the wrapper behind a platform-specific cfg:• libc::WIFSIGNALED
• libc::WIFSTOPPED
• libc::WIFEXITED
• libc::WTERMSIG
• libc::WSTOPSIG
• libc::WEXITSTATUSRecommendations:
- Add a minimal compile-time assertion in a test crate (e.g.
const _: bool = your_wrapper(0);) and include it in CI.- If a macro fails to be const on any supported platform, convert its wrapper to a regular
fnor use#[cfg(...)]to only applyconst fnwhere supported.common/src/linked_list.rs (3)
196-204: LGTM: Simple Option check is appropriate for const fn.This function only checks if an Option is None, which is well-suited for compile-time evaluation.
326-334: UnsafeCell::new() is const-evaluable in current RustTests confirm that
UnsafeCell::new()can be used within aconst fn(it compiles without errors when built as a library), soPointers::new()is valid as written.
336-371: Const pointer operations are const-evaluable – no changes neededI verified that both
ptr::readandptr::writecan be used inconst fnon current stable Rust (compiled as a library with metadata-only emission), so these getters and setters compile cleanly in a const context.– No further action required.
vm/src/builtins/asyncgenerator.rs (4)
32-34: LGTM: Simple reference return is appropriate for const fn.This getter method only returns a reference to an existing field, which is well-suited for compile-time evaluation.
79-81: LGTM: Returning self is appropriate for const fn.This method simply returns the receiver, which is well-suited for compile-time evaluation.
204-206: LGTM: Returning self is appropriate for const fn.These
__await__methods simply return the receiver, which is well-suited for compile-time evaluation.Also applies to: 298-300
89-95: VerifyAtomicCell::newIs Const-EvaluableThe
asendconstructor is aconst fnand usesAtomicCell::new(...). Depending on yourcrossbeam-utilsversion,AtomicCell::newmay not be markedconst, causing a compilation error.• Check your
Cargo.tomlfor thecrossbeam-utilsversion in use.
• Confirm in that crate’ssrc/atomic/cell.rsthatpub const fn new(...)is defined (added in ≥0.8.x).
• If your version predates theconst fnchange, either bumpcrossbeam-utilsor refactorasendto avoid requiringconst.compiler/core/src/bytecode.rs (2)
217-219:const fnwith interior mutation looks good
resetonly performs a single assignment; this is accepted by stableconstevaluation, so the new qualifier is safe. No action needed.
283-285: Const-qualification of pure helpers LGTMMarking
Arg::marker,CodeUnit::new,Instruction::label_arg, andInstruction::unconditional_branchasconst fnis valid; they are side-effect free (or take only immutable args) and don’t call non-const APIs. This increases compile-time usability without affecting runtime behaviour.Also applies to: 663-665, 1153-1169, 1180-1190
vm/src/stdlib/io.rs (9)
292-294: Double-check MSRV forCursor::positionbeingconst
const fn tellnow callsCursor::position(). This is only legal if the MSRV you advertise already providesconst fn position(stabilised in 1.77). If you still support an older toolchain the build will fail.No change requested – just make sure the CI matrix covers the oldest supported compiler.
785-804:BufferedDataflag helpers converted toconst fn– looks goodAll helpers merely read bit-flags and do arithmetic; bitflags 2.x exposes
const fn contains, so this compiles fine and allows use in other const contexts.
806-813:raw_offsetpromoted to const – all operations are const-safeThe implementation only does comparisons and arithmetic on plain integers, so the new qualifier is sound.
815-822:readaheadconst-ification is safeSame reasoning as above; no hidden I/O or heap work.
823-830:reset_read/reset_writeare nowconstbut mutate&mut selfMutating fields is allowed inside a
const fnwith a&mut selfreceiver, so this is fine.
1281-1286:adjust_positionconst-readySimple field updates only; no concerns.
2099-2101:textio_encode_utf8asconst fn– harmlessConstructing an enum variant is allowed in const context. No objections.
2267-2270:TextIOCookie::set_num_to_skipconst-ification OKPure field assignments; approved.
1908-1914: Const getters on pyclass methods – verify macro support
#[pymethod] const fn ...relies on thepymethodmacro accepting theconstkeyword. RustPython’s proc-macro already handles this for other modules, so this should compile, but keep an eye on CI in case of a downstream macro regression.Also applies to: 3515-3527, 3641-3653
vm/src/stdlib/posix.rs
Outdated
| @@ -1228,7 +1228,7 @@ pub mod module { | |||
| } | |||
|
|
|||
| #[pyfunction] | |||
| 67E6 | fn sync() { | ||
| const fn sync() { | |||
There was a problem hiding this comment.
#[pyfunction], #[pymethod], #[pygetset] etc will have no change to be called in const context. you don't need to spend too much effort about them.
const fn to rust-context functions is a good idea
There was a problem hiding this comment.
#[pyfunction], #[pymethod], #[pygetset] etc will have no change to be called in const context. you don't need to spend too much effort about them.
It's a simple clippy command:)
Summary by CodeRabbit