The bang entry overshot, and the zero-padded hour needs a warning - #432
Merged
Conversation
…warning Two corrections, both found by downstream projects bumping to 0.17.0. The 0.16.0 entry for `!` claimed more than the feature does. Its title is right -- it negates a condition -- but the body then offered `! true && true` as `(! true) && true`, which is a statement-level use that has never parsed. kaibo read the entry as a promise while bumping, wrote the form, and got a parse error at 1:1. The entry now says what is true and names the boundary: a condition, not a statement. The parser has only ever grown `!` in condition position (parser.rs:2898), where it folds before `&&`/`||`. `Stmt` has AndChain and OrChain and no negation, so there was nothing for a statement-level `!` to become. That is a feature, tracked separately; the changelog should not have implied it shipped. The migration note is the sharper of the two. 0.17.0 refuses a leading zero wherever a number is required, which is correct and which fails loudly -- except in one shape, where it fails on a schedule. A zero-padded time field in a numeric comparison is a type error for 00 through 09 and correct from 10 on: ``` hour=$(date '+%H') [[ "$hour" -lt 6 ]] ``` That passes every test run made during the working day and fails overnight. kaijutsu caught it in a quiet-hours script only because they pin their rc idioms in a test; without that it would have shipped green and broken at an hour with no one watching. kaish-extras reported the same shape independently, which is why it earns a note rather than a mention. Their script's own comment had argued that numeric comparison was the safe choice, because it avoided the leading-zero trap in `case` and `for`. 0.17.0 inverts that reasoning, so a reader who got it right under 0.16 is now holding the broken form. The note names the fix both ways: `%-H` for an unpadded field, `10#$hour` to read a padded one.
tobert
force-pushed
the
docs/changelog-corrections
branch
from
September 2, 2026 12:21
8a7d25d to
a9fe611
Compare
Merged
tobert
added a commit
that referenced
this pull request
Sep 2, 2026
Version bump and changelog stamp for v0.17.1, a patch release covering six PRs merged since v0.17.0: help/kaish-tools nested-subcommand recursion (#430), the wrapped-command allow_external_commands framing correction (#431), a changelog correction plus a new zero-padded date/time migration note (#432), nested verb groups for wrapped commands (#433), mount-point ancestor navigation when a backend also covers `/` (#435), and VfsRouter-shared path canonicalization closing a containment leak in `readlink -f`/`realpath` (#434). This bump also carries two documentation fixes surfaced by the release-gate review below rather than opening a separate PR for text-only changes: `docs/EMBEDDING.md` claimed `realpath` passes `allow_missing_final: true` and rechecks existence, when it actually passes `false` directly; and the canonicalize changelog entry overstated the default implementation as containment-checked, when containment is a property of `LocalFs`'s and `VfsRouter`'s overrides, not the shared default. Reviewed with kaibo (`consult`, cast `deepseek`) against the full `v0.17.0..HEAD` diff. Verdict: no undocumented semver breaks — the two new `canonicalize` trait methods are defaulted and every changed public type is either `#[non_exhaustive]` or privately fielded, so the patch framing holds. Two smaller findings from that review are real but scoped as code changes rather than release-blocking text, so they're queued as follow-up work rather than folded into this bump: a wrapped-command node can silently accept a no-op `json_output` declaration instead of being refused, and the new `canonicalize` default's symlink-hop cap has thin test coverage. Gates: `cargo test --all` (2231 passed), `cargo clippy --all --all-targets -- -D warnings` (clean), `cargo insta test --check` (no pending snapshots).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two changelog corrections, both found by downstream projects bumping to 0.17.0.
The 0.16.0 entry for
!claimed more than the feature does. Its title is right — it negates a condition — but the body offered! true && trueas(! true) && true, which is a statement-level use that has never parsed:kaibo read the entry as a promise while bumping, wrote the form, and got that. The parser has only ever grown
!in condition position, andStmthasAndChainandOrChainand no negation, so there was nothing for a statement-level!to become. The entry now says what is true and names the boundary.The migration note is the sharper of the two. 0.17.0 refuses a leading zero wherever a number is required, which is correct and fails loudly — except in one shape, where it fails on a schedule:
That is a type error for
00through09and correct from10on, so it passes every test run made during the working day and fails overnight. kaijutsu caught it in a quiet-hours script only because they pin their rc idioms in a test; kaish-extras reported the same shape independently.Their script's own comment had argued numeric comparison was the safe choice because it avoided the leading-zero trap in
caseandfor. 0.17.0 inverts that reasoning, so a reader who got it right under 0.16 is now holding the broken form. The note names the fix both ways:%-Hfor an unpadded field,10#$hourto read a padded one.