Formatter: discarded `checked_sub` never reserves separator width in one-per-line `SeparatedExprs`
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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;
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.
- 主要言語
- Rust
- スター
- 10.9k
- フォーク
- 261
- 平均マージ
- 3日 21時間
- マージ済み PR（30日）
- 84
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
PRQL/prql のほかの issue
-
Underscore does not work as expected対応中かも @prql-bot が 1 日前に担当しました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 3 日以内に返信
-
prqlc Debug Report HTML Does Not Escape Source File Name, Enabling Stored XSS via PRQLC_DEBUG_LOGオープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 3 日以内に返信
-
friendliness integrations
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
PRQL/prql#1636 · コメント 2 件 · リアクション 2 件 ·
メンテナーはふだん 3 日以内に返信
-
難易度 4/5 1〜2日 初心者へのやさしさ 12/100
メンテナーはふだん 3 日以内に返信
-
review-runs-tracking
難易度 3/5 半日 初心者へのやさしさ 5/100
メンテナーはふだん 3 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
could docs good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
README em inglêsオープンgood first issue help wanted priority:p2 type:docs
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
lucacasanova/homedeck#122 ·
-
needs-triage
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
bherbruck/solvecraft#11729 · コメント 1 件 · リアクション 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信