Use `const fn` where possible by ShaharNaveh · Pull Request #5894 · RustPython/RustPython

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.

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.

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.

81-86: LGTM: Excellent const fn usage enabling static initialization.

The const fn qualifier is perfectly appropriate here since both RawThreadMutex::INIT and UnsafeCell::new are const. This enables static initialization of ThreadMutex instances, which is particularly valuable for synchronization primitives.

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 Readline instances when the helper parameter supports const construction.

80-80: LGTM: Appropriate const fn conversion.

The from_inner function is a simple constructor that only initializes struct fields with basic operations, making it suitable for const evaluation.

138-140: LGTM: Appropriate const fn conversion.

The log_mask function performs a simple bit shift operation which is const-eligible.

144-146: LGTM: Appropriate const fn conversion.

The log_upto function performs simple arithmetic operations on primitive integers, making it suitable for const evaluation.

122-128: LGTM: Appropriate const fn conversion.

The len method performs pattern matching and calls to const functions (Wtf8::len and CodePoint::len_wtf8), making it suitable for const evaluation.

276-278: LGTM: Perfect const fn candidate.

The maxlen getter is a simple field access operation, which is ideal for const evaluation.

163-170: LGTM: Appropriate const fn conversion.

The unhex_nibble function performs pattern matching and simple arithmetic on primitive types, making it suitable for const evaluation.

813-819: LGTM: Appropriate const fn conversion.

The uu_b2a function performs simple conditional logic and arithmetic on primitive types, making it suitable for const evaluation.

86-88: LGTM! Appropriate const fn conversion.

This simple constructor is an ideal candidate for const fn as it performs only struct field assignment without side effects, enabling compile-time evaluation.

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.

108-118: LGTM! Excellent const fn candidate.

This constructor performs only simple field assignments without side effects, making it an ideal candidate for const fn and enabling compile-time instantiation of TypeAliasType.

42-44: LGTM! Valid const fn for unimplemented function.

Since this function is currently unimplemented (TODO), marking it as const fn is 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.

167-175: LGTM! Perfect const fn candidate.

This function performs only a simple type cast operation, making it an excellent candidate for const fn and enabling compile-time hash calculations.

178-180: LGTM! Proper const fn composition.

This function correctly composes two const functions (hash_object_id_raw and fix_sentinel), making it appropriately qualified as const fn.

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.

140-152: LGTM! Appropriate const unsafe fn conversion.

The unsafe operations (split_at_unchecked and from_utf8_unchecked) are const-compatible, and the function logic is suitable for compile-time evaluation.

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.

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.

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 Ok is const-compatible.

88-88: LGTM: Appropriate const fn conversion.

Converting fd() to const fn is 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() to const fn is correct for the non-Windows implementation since it only returns a constant Ok(false), enabling compile-time evaluation.

645-645: LGTM: Appropriate const fn conversion.

Converting __enter__() to const fn is correct since it only returns the input parameter zelf, which is a simple operation suitable for compile-time evaluation.

1498-1498: LGTM: Appropriate const fn conversion.

Converting SupportFunc::new() to const fn is correct since it's a simple constructor that only assigns parameters to struct fields, enabling compile-time instantiation.

98-98: LGTM: Appropriate const fn conversion.

Converting default_prefix() to const fn is correct since it only returns string literals based on compile-time cfg!() conditions, enabling compile-time evaluation.

241-241: LGTM: Appropriate const fn conversion.

Converting meta_path() to const fn is correct since it only returns Vec::new(), which is const-compatible and enables compile-time evaluation.

261-261: LGTM: Appropriate const fn conversion.

Converting path_hooks() to const fn is correct since it only returns Vec::new(), which is const-compatible and enables compile-time evaluation.

457-457: LGTM: Appropriate const fn conversion.

Converting getdefaultencoding() to const fn is correct since it only returns a constant reference crate::codecs::DEFAULT_ENCODING, enabling compile-time evaluation.

967-967: LGTM: Appropriate const fn conversion.

Converting Flags::from_settings() to const fn is correct since it only performs simple field assignments and type conversions (boolean to u8 casts) that are const-compatible, enabling compile-time struct creation.

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(), and f32::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 fn evaluation.

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 fn evaluation.

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.

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 verified

The check_and_fill! macro expands to simple field assignments and the if let branches only perform pattern matching and assignments—no function calls or unsupported operations. All constructs (if, if let, local mutations) are supported in a const fn on stable Rust. No changes needed.

69-71: LGTM: Generic function returning const associated item.

The flush_sync function returns T::SYNC which is a const associated item, making this conversion appropriate for compile-time evaluation.

79-84: LGTM: Constructor patterns are ideal for const fn.

Both new and chain constructors 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 len method performs arithmetic on field lengths, and is_empty calls the const is_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

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 false values 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_method and S_IFMT_method perform 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 filetype function 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.

36-38: LGTM: Simple constructor ideal for const fn.

The new method 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.

399-401: LGTM: Bitflags accessor method is const-compatible.

The flags method calls bits() on a SreFlag field. Since SreFlag appears to be a bitflags type and bitflags typically provide const bits() methods, this conversion is appropriate for enabling compile-time evaluation.

234-236: LGTM: Valid const function conversion.

The __abs__ method correctly uses const fn since it only calls self.value.abs() on an f64, which is const-compatible. This change enables compile-time evaluation without altering the method's behavior.

55-57: LGTM: Valid const function conversion.

The as_tuple method correctly uses const fn since it only returns a reference to an inner field (&self.0). This is a simple accessor that can be evaluated at compile time.

45-47: LGTM: Valid const function conversion.

The args method correctly uses const fn since it only returns a reference to the args field (&self.args). This simple accessor method can be evaluated at compile time while maintaining compatibility with CPython's _Py_union_args.

139-148: LGTM: Valid const function conversion.

The sign_string method correctly uses const fn since it only performs const-compatible operations: contains() calls on bitflags and returns static string literals. The conditional logic can be evaluated at compile time.

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.

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 for const 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 for const fn. This follows the same pattern as the PyNone implementation.

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.

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_empty method delegates to the inner type's emptiness check, maintaining consistency with similar implementations across other collection types in the codebase.

119-121: LGTM! Appropriate const fn for pointer accessor.

The as_ptr method delegates to the standard library's slice.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_msg method performs simple pattern matching returning compile-time string literals, making it an ideal candidate for const fn with no runtime dependencies or side effects.

133-135: LGTM - Valid const fn conversion

This constructor function correctly converts to const fn since it only performs simple struct field assignment. This enables compile-time evaluation of ArgMapping instances when the arguments are known at compile time.

50-55: LGTM - Valid const fn conversion for PositionIterInternal

This constructor correctly converts to const fn since it only performs enum construction and field assignment. This enables compile-time instantiation of PositionIterInternal instances.

259-264: LGTM - Valid const fn conversion for PyCallableIterator

This constructor correctly converts to const fn. The use of PyRwLock::new is appropriate since it's typically implemented as a const fn in standard library implementations.

31-37: Verify const fn compatibility with Box<str> in StringParser::new (compiler/codegen/src/string_parser.rs:31–37)

We weren’t able to run a full cargo check in the sandbox due to toolchain errors. Before merging, please:

• Manually confirm that StringParser::new(source: Box<str>, flags: AnyStringFlags) -> Self compiles 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 the Box<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.

285-292: PatternContext::new safely promoted to const fn – looks good

Vec::new() and the other operations used here are all const-stable on the MSRV you’re already targeting, so this change compiles on stable and widens the function’s usability without side-effects.

418-425: LGTM! Appropriate use of const fn

Both from_adjust_indices and positive_order methods are good candidates for const fn as they only perform simple arithmetic operations and conditional logic that are available in constant evaluation contexts. The use of is_negative(), saturating_sub(), and saturating_abs() are all const-compatible operations.

Also applies to: 427-433

725-727: LGTM! Simple constructor perfect for const fn

This 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 as const fn

The PyCell::new constructor only creates a struct with a PyMutex, which should be const-compatible. This change is consistent with similar constructor patterns in the codebase.

204-210: LGTM! Appropriate const fn for simple pattern matching

The arg_count method only performs pattern matching on an enum and returns either constants or field values, making it an excellent candidate for const fn.

289-297: LGTM! Alignment calculation function suitable for const fn

The compensate_alignment function uses only const-compatible operations including arithmetic, bit operations, and checked_sub. The logic is purely computational without side effects, making it appropriate for compile-time evaluation.

447-449: LGTM! Simple getter perfect for const fn

This is a straightforward field accessor that returns the size field, making it an ideal candidate for const fn. This pattern is consistent with similar const getters found in stdlib/src/pystruct.rs line 262-264.

165-170: LGTM! Appropriate const fn conversion.

The is_global method uses only const-compatible operations (matches! macro with enum pattern matching) and has no side effects, making it a good candidate for const fn.

172-174: LGTM! Appropriate const fn conversion.

The is_local method uses only const-compatible operations and is a pure function, making it suitable for const fn.

176-178: LGTM! Appropriate const fn conversion.

The is_bound method uses intersects on bitflags which is const-compatible, and this change enables the method to be used in the const contexts shown in the relevant snippets.

35-37: LGTM! Appropriate const fn conversion.

The new constructor performs only simple field assignments, making it a perfect candidate for const fn. This enables compile-time construction of Unparser instances.

605-607: LGTM! Appropriate const fn conversion.

The unparse_expr function is a simple constructor that creates a struct with two fields, making it suitable for const fn and enabling compile-time creation of UnparseExpr instances.

50-52: LGTM! Appropriate const fn conversion.

Simple field getter that returns a primitive value, perfect for const fn.

55-57: Verify that LineNumber::get() is a const fn.

I wasn’t able to locate the implementation of LineNumber::get in 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 a const fn tb_lineno() remains valid.

30-42: Confirm that PyMutex::new is a const fn.

The const fn new on PyTraceback hinges on PyMutex::new being const. Since

pub type PyMutex<T> = Mutex<RawMutex, T>;

is just an alias for lock_api::Mutex<RawMutex, T>, please verify that in your lock_api version
Mutex::new(...) is indeed declared as const fn. If it isn’t, you’ll need to either:

• Upgrade to a lock_api release where Mutex::new is const fn.
• Or provide a small const fn wrapper/alias in common/src/lock.rs (e.g., const fn new_mutex<T>(t: T) -> PyMutex<T> { Mutex::new(t) }).

121-123: LGTM! Appropriate const fn conversion.

The unsafe transmute_copy operation is const-compatible and this method is a good candidate for const 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.

76-78: Appropriate conversion to const 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 to const fn for getter method.

This simple getter method returns a field value without side effects, making it appropriate for compile-time evaluation.

629-631: Good conversion to const fn for getter method.

This simple getter method returns a field value without side effects, making it appropriate for compile-time evaluation.

39-42: Appropriate conversion to const fn for builder method.

This method performs a simple field modification and return, making it suitable for compile-time evaluation.

53-58: Good conversion to const fn for conditional getter.

This method performs simple flag checking and returns a reference conditionally, which is appropriate for compile-time evaluation.

122-125: Appropriate conversion to const fn for simple getter.

This method returns a static string field without side effects, making it suitable for compile-time evaluation.

32-34: Appropriate conversion to const fn for constructor.

This simple wrapper constructor performs no side effects and is suitable for compile-time evaluation.

173-175: Good conversion to const fn for predicate method.

This method calls self.symbol.is_global() (which is const fn based on the relevant code snippet from compiler/codegen/src/symboltable.rs) and performs boolean logic, making it appropriate for compile-time evaluation.

183-185: Good conversion to const fn for predicate method.

This method calls self.symbol.is_local() (which is const fn based on the relevant code snippet from compiler/codegen/src/symboltable.rs) and performs boolean logic, making it appropriate for compile-time evaluation.

193-196: Appropriate conversion to const fn for trivial function.

This method simply returns a constant value, making it clearly suitable for compile-time evaluation.

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 fn qualifier 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.

28-30: LGTM: Consistent const fn pattern across coroutine types.

This accessor method returns a reference to the internal Coro field, which is appropriate for const fn. The change aligns with identical patterns in generator.rs and asyncgenerator.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 PyCoroutineWrapper through simple struct construction, making it suitable for const 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 for const fn. The unused _vm parameter doesn't prevent const evaluation since the method body only returns a compile-time constant.

416-424: Accessor safely promoted to const fn – looks good

The new const qualifier on as_wtf8 / as_bytes is correct:
• both simply delegate to already-const helpers on StrData / Wtf8;
• no proc-macro attributes are attached, so nothing blocks compile-time evaluation.

No further action required.

459-471: kind() / is_utf8() now const – LGTM

These trivial getters don’t rely on anything non-const and will be usable in
const contexts immediately.

604-606: Verify #[pymethod] const fn macro expansion

The sandbox build failed due to a missing C linker (cc not found), so we couldn’t confirm that the #[pymethod] proc-macro still handles const fn. Please verify on your local machine:

• Install a C linker (e.g. gcc / build-essential).
• Run cargo check or cargo test to ensure the build succeeds.
• Optionally use cargo expand on the is_ascii method in vm/src/builtins/str.rs (lines 604–606) to inspect the generated binding named "isascii".

370-373: Constifying simple predicates is fine

is_linebreak / is_uni_linebreak are pure value checks; marking them const
poses no problems.

Also applies to: 436-441

205-208: Constructor can safely be const

PyCode::new is a plain struct literal – upgrading to const is harmless and
useful for embedding byte‐code blobs in future const contexts.

245-258: Const getters with #[pygetset] are supported
Inspected the pygetset procedural macro (in derive/src/lib.rs → derive-impl) and confirmed it forwards the complete function signature (including const) via #sig. There’s no special pattern-match excluding const fn, so your const-qualified getters will be preserved correctly. No changes required.

152-154: LGTM: Appropriate const fn conversion

The has_feature method only performs bitwise operations via contains(), making it suitable for const fn.

157-159: LGTM: Appropriate const fn conversion

The is_created_with_flags method only performs bitwise flag checking, making it suitable for const fn.

328-330: LGTM: Appropriate const fn conversion

The self_iter function only returns its parameter wrapped in Ok(), making it suitable for const fn.

1112-1119: LGTM: Appropriate const fn conversion

The eval_ord method only performs pattern matching and bitwise operations, making it suitable for const fn.

1121-1130: LGTM: Appropriate const fn conversion

The swapped method only performs pattern matching and returns enum variants, making it suitable for const fn.

31-33: LGTM: Appropriate const fn conversion

The to_complex64 method only returns a field value, making it suitable for const fn.

239-241: LGTM: Appropriate const fn conversion

The to_complex method only returns a field value, making it suitable for const fn.

250-252: LGTM: Appropriate const fn conversion

The real getter only returns a field from the complex value, making it suitable for const fn.

255-257: LGTM: Appropriate const fn conversion

The imag getter only returns a field from the complex value, making it suitable for const fn.

349-351: LGTM: Appropriate const fn conversion

The __pos__ method only returns the complex value, making it suitable for const fn.

387-390: LGTM: Appropriate const fn conversion

The __getnewargs__ method only destructures the complex value and returns a tuple of primitives, making it suitable for const fn. Note that this differs from the float/int implementations which take a VM parameter, but this implementation is simpler and can be const.

424-428: LGTM: Appropriate const fn conversion

The InstanceDict::new method only wraps the parameter in a PyRwLock::new(), which is const in Rust standard library.

515-519: LGTM: Appropriate const fn conversion

The into_raw method only extracts the pointer and forgets self, which are compile-time operations suitable for const fn.

527-529: LGTM: Appropriate const unsafe fn conversion

The from_raw method only creates a struct from a raw pointer, which is a compile-time operation suitable for const unsafe fn.

666-671: LGTM: Appropriate const unsafe fn conversion

The payload_unchecked method only performs pointer casting operations, which are compile-time operations suitable for const unsafe fn.

1029-1033: LGTM: Appropriate const unsafe fn conversion

The from_raw method only creates a struct from a raw pointer using NonNull::new_unchecked, which are compile-time operations suitable for const unsafe fn.

1053-1057: LGTM: Appropriate const fn conversion

The leak method only extracts the pointer and forgets the object, which are compile-time operations suitable for const fn.

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 macros

The CI environment couldn’t complete the Rust compilation test, so you’ll need to manually confirm that these wrappers actually compile as const fn on your supported targets. If any of the following macros aren’t const-evaluable, you’ll need to remove the const qualifier or gate the wrapper behind a platform-specific cfg:

• libc::WIFSIGNALED
• libc::WIFSTOPPED
• libc::WIFEXITED
• libc::WTERMSIG
• libc::WSTOPSIG
• libc::WEXITSTATUS

Recommendations:

• 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 fn or use #[cfg(...)] to only apply const fn where supported.

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 Rust

Tests confirm that UnsafeCell::new() can be used within a const fn (it compiles without errors when built as a library), so Pointers::new() is valid as written.

336-371: Const pointer operations are const-evaluable – no changes needed

I verified that both ptr::read and ptr::write can be used in const fn on 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.

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: Verify AtomicCell::new Is Const-Evaluable

The asend constructor is a const fn and uses AtomicCell::new(...). Depending on your crossbeam-utils version, AtomicCell::new may not be marked const, causing a compilation error.

• Check your Cargo.toml for the crossbeam-utils version in use.
• Confirm in that crate’s src/atomic/cell.rs that pub const fn new(...) is defined (added in ≥0.8.x).
• If your version predates the const fn change, either bump crossbeam-utils or refactor asend to avoid requiring const.

217-219: const fn with interior mutation looks good

reset only performs a single assignment; this is accepted by stable const evaluation, so the new qualifier is safe. No action needed.

283-285: Const-qualification of pure helpers LGTM

Marking Arg::marker, CodeUnit::new, Instruction::label_arg, and Instruction::unconditional_branch as const fn is 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

292-294: Double-check MSRV for Cursor::position being const

const fn tell now calls Cursor::position(). This is only legal if the MSRV you advertise already provides const 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: BufferedData flag helpers converted to const fn – looks good

All 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_offset promoted to const – all operations are const-safe

The implementation only does comparisons and arithmetic on plain integers, so the new qualifier is sound.

815-822: readahead const-ification is safe

Same reasoning as above; no hidden I/O or heap work.

823-830: reset_read / reset_write are now const but mutate &mut self

Mutating fields is allowed inside a const fn with a &mut self receiver, so this is fine.

1281-1286: adjust_position const-ready

Simple field updates only; no concerns.

2099-2101: textio_encode_utf8 as const fn – harmless

Constructing an enum variant is allowed in const context. No objections.

2267-2270: TextIOCookie::set_num_to_skip const-ification OK

Pure field assignments; approved.

1908-1914: Const getters on pyclass methods – verify macro support

#[pymethod] const fn ... relies on the pymethod macro accepting the const keyword. 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