Formatter: discarded `checked_sub` never reserves separator width in one-per-line `SeparatedExprs`

Đang mở
  • Có gì không ổn?
#6,085 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 4 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
rust
Lĩnh vực
tooling

Hướng nghiên cứu

Read prqlc/prqlc/src/codegen/mod.rs around SeparatedExprs::write and compare it with write_inline's consume_width behavior; prqlc/prqlc/src/codegen/ast.rs defines the separator. Run the formatter snapshot tests and inspect cases near the width boundary. The issue explicitly leaves the intended formatter behavior to a maintainer decision; confirm that decision before changing snapshots.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

The nightly code-quality survey flagged a discarded computation in the code formatter that looks like it was meant to reserve width for a trailing separator but doesn't.

In SeparatedExprs::write, the one-per-line branch does:

opt.reset_line()?;
opt.rem_width.checked_sub(self.line_end.len() as u16)?;   // result discarded

r += &expr.write(opt.clone())?;
r += self.line_end;

codegen/mod.rs:168-172

checked_sub is non-mutating, so its result is thrown away — the line only functions as an underflow guard (via ?), it never actually reserves the line_end width before expr.write. Compare the sibling write_inline path, which uses the mutating consume_width to charge width against rem_width.

line_end is "," for tuples and arrays (ast.rs:103-114). Because the separator width is never reserved, an element that exactly fills the remaining width leaves no room for the trailing ,, so that formatted line can exceed max_width by one character.

This is a minor cosmetic edge case, not a correctness bug in the emitted PRQL. But the current line is either a latent off-by-line_end.len() bug (should be opt.consume_width(self.line_end.len() as u16)?; to actually reserve the separator) or the reservation is unwanted and the line is redundant. Which of the two is the intended behavior is a formatter-design call, and changing it would shift fmt snapshot output for elements near the width boundary — so flagging for a maintainer decision rather than opening a speculative PR.

Found during the nightly survey of codegen/mod.rs.

Ngôn ngữ chính
Rust
Star
10.9k
Fork
261
Merge trung bình
4 ngày 6 giờ
Pull request đã merge (30 ngày)
78

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của PRQL/prql

Tất cả issue của PRQL/prql

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.