Remove deprecated io.read-line+ builtin #456

Closed

dooc2 wants to merge 0 commits from dooc2/remove-io-read-line-plus into main AGit

dooc2 commented

2026-05-05 17:51:02 +00:00

First-time contributor

Covers full end-to-end removal:

ast/program.rs: remove name registration entry
builtins/io.rs: remove builtin! sig and docs.insert entry
codegen/runtime/stdio.rs: remove LLVM declare and symbol mapping
runtime/io.rs: remove patch_seq_read_line_plus function and its pub use
runtime/lib.rs: remove re-export of read_line_plus

Closes #455

Covers full end-to-end removal: - ast/program.rs: remove name registration entry - builtins/io.rs: remove builtin! sig and docs.insert entry - codegen/runtime/stdio.rs: remove LLVM declare and symbol mapping - runtime/io.rs: remove patch_seq_read_line_plus function and its pub use - runtime/lib.rs: remove re-export of read_line_plus Closes #455

dooc2 added 1 commit

2026-05-05 17:51:02 +00:00

Remove deprecated io.read-line+ builtin

CI - Linux / CI - Linux x86_64 (pull_request) Failing after 7s

Details

0fc3a8b9e0

Covers full end-to-end removal:
- ast/program.rs: remove name registration entry
- builtins/io.rs: remove builtin! sig and docs.insert entry
- codegen/runtime/stdio.rs: remove LLVM declare and symbol mapping
- runtime/io.rs: remove patch_seq_read_line_plus function and its pub use
- runtime/lib.rs: remove re-export of read_line_plus

Closes #455

navicore commented

2026-05-05 18:48:46 +00:00

Owner

Scope is correct and complete. All 9 callsites that exist on main are removed, and git grep on the PR branch finds zero stragglers across .rs, .md, .psr, and .toml — so the end-to-end claim in the description holds.

Bug — orphaned doc comment block in crates/runtime/src/io.rs. The function-level docstring for patch_seq_read_line_plus was only partially deleted. Lines 166–179 of the post-PR file are leftover doc lines from the removed function, but they are now syntactically attached to READ_N_MAX_BYTES on line 183. The result reads:

/// Read a line from stdin with explicit EOF detection
///
/// Returns the line and a status flag:
/// - ( line 1 ) on success (line includes trailing newline)
/// - ( "" 0 ) at EOF or I/O error
///
/// Stack effect: ( -- String Int )
///
/// The `+` suffix indicates this returns a result pattern (value + status).
/// Errors are values, not crashes.
///
/// # Line Ending Normalization
///
/// Line endings are normalized to `\n` regardless of platform. Windows-style
/// Maximum bytes allowed for a single read_n call (10MB)
/// This prevents accidental or malicious massive memory allocations.
/// LSP messages are typically < 1MB, so 10MB provides generous headroom.
const READ_N_MAX_BYTES: i64 = 10 * 1024 * 1024;

Note the broken sentence at lines 179–180: Windows-style flows directly into Maximum bytes allowed for a single read_n call. This will show up in cargo doc output for the constant. Fix is to delete lines 166–179 (everything from /// Read a line from stdin... through /// Line endings are normalized to \n regardless of platform. Windows-style), so READ_N_MAX_BYTES keeps only its own three-line doc.

Nice catch in the same file. Line 210's doc was correctly updated from Like io.read-line+ → Like io.read-line. Good.

**Scope is correct and complete.** All 9 callsites that exist on `main` are removed, and `git grep` on the PR branch finds zero stragglers across `.rs`, `.md`, `.psr`, and `.toml` — so the end-to-end claim in the description holds. **Bug — orphaned doc comment block in `crates/runtime/src/io.rs`.** The function-level docstring for `patch_seq_read_line_plus` was only partially deleted. Lines 166–179 of the post-PR file are leftover doc lines from the removed function, but they are now syntactically attached to `READ_N_MAX_BYTES` on line 183. The result reads: ```rust /// Read a line from stdin with explicit EOF detection /// /// Returns the line and a status flag: /// - ( line 1 ) on success (line includes trailing newline) /// - ( "" 0 ) at EOF or I/O error /// /// Stack effect: ( -- String Int ) /// /// The `+` suffix indicates this returns a result pattern (value + status). /// Errors are values, not crashes. /// /// # Line Ending Normalization /// /// Line endings are normalized to `\n` regardless of platform. Windows-style /// Maximum bytes allowed for a single read_n call (10MB) /// This prevents accidental or malicious massive memory allocations. /// LSP messages are typically < 1MB, so 10MB provides generous headroom. const READ_N_MAX_BYTES: i64 = 10 * 1024 * 1024; ``` Note the broken sentence at lines 179–180: `Windows-style` flows directly into `Maximum bytes allowed for a single read_n call`. This will show up in `cargo doc` output for the constant. Fix is to delete lines 166–179 (everything from `/// Read a line from stdin...` through `/// Line endings are normalized to \n regardless of platform. Windows-style`), so `READ_N_MAX_BYTES` keeps only its own three-line doc. **Nice catch in the same file.** Line 210's doc was correctly updated from `Like io.read-line+` → `Like io.read-line`. Good.

dooc2 added 1 commit

2026-05-05 18:57:58 +00:00

Remove orphaned doc comment from deleted patch_seq_read_line_plus

CI - Linux / CI - Linux x86_64 (pull_request) Failing after 7s

Details

b7a324b850

Lines 166-179 were the function-level docstring for the removed
patch_seq_read_line_plus function. They survived the deletion and got
attached to READ_N_MAX_BYTES, producing broken cargo doc output.

dooc2 commented

2026-05-05 18:58:12 +00:00

Author

First-time contributor

Fixed — removed the 14-line orphaned doc comment block from the deleted patch_seq_read_line_plus function. READ_N_MAX_BYTES now has only its own 3-line doc. Build + full test suite (1,083 tests) still passes.

Fixed — removed the 14-line orphaned doc comment block from the deleted `patch_seq_read_line_plus` function. `READ_N_MAX_BYTES` now has only its own 3-line doc. Build + full test suite (1,083 tests) still passes.

navicore commented

2026-05-05 19:14:28 +00:00

Owner

#458

https://git.navicore.tech/navicore/patch-seq/pulls/458

navicore closed this pull request

2026-05-05 19:14:28 +00:00