docs: only from_days is unstable, and I attributed one error to two constructors #123

Merged

jlxq0 merged 1 commit from duration-claim into main

2026-09-02 02:36:53 +00:00

jlxq0 commented

2026-08-26 05:18:29 +00:00

Owner

Docs only. Corrects a claim in AGENTS.md that I wrote this morning and that is half false.

The entry said all eleven duration_suboptimal_units allows suppress advice that does not compile, because Duration::from_mins/from_days are "still unstable on 1.98". Probed separately, one constructor per file, in const context:

	1.93.0	1.98.0
`from_mins`	const-stable	const-stable
`from_hours`	const-stable	const-stable
`from_days`	`E0658`	`E0658`

Only from_days is unstable, and it is unstable on 1.98 too — so pinning the toolchain forward never retires it.

How the error happened, because it is the same class the file is about: my original probe put both constructors in one source file, got a single E0658, and attributed it to both. An error message read as being about more than it was about — written directly beneath a bullet telling the reader to check a suppression's stated reason before trusting it.

Found by the hevy-mcp lead, which hit the same false sentence in its own src/session.rs above a from_secs(30 * 60), compiled from_mins(30) on 1.93.0 first try, and deleted both of its allows rather than pinning them.

What is actually true here. session_store.rs's from_secs(7 * 24 * 60 * 60) genuinely needs its allow — from_days(7) does not compile on either toolchain. The seven over from_secs(60), from_secs(5 * 60), from_secs(15 * 60), from_secs(30 * 60), from_secs(300), from_secs(1800) and from_secs(120) are suppressing advice that compiles on the MSRV.

Not removing them in this PR. That is a code change wanting a full gate run, and this PR is the file that was wrong about it. Whoever picks that up should compile rather than trust the new bullet — which now says so, and says that this bullet has itself been wrong once.

unused_async_trait_impl is unaffected and still needs its allow: it fires on #[tool_handler]-generated code and is what puts the lint floor at 1.98.

No code, no tests, no gate impact.

Docs only. Corrects a claim in `AGENTS.md` that I wrote this morning and that is half false. The entry said all eleven `duration_suboptimal_units` allows suppress advice that does not compile, because `Duration::from_mins`/`from_days` are "still unstable on 1.98". Probed separately, one constructor per file, in const context: | | 1.93.0 | 1.98.0 | |---|---|---| | `from_mins` | const-stable | const-stable | | `from_hours` | const-stable | const-stable | | `from_days` | `E0658` | `E0658` | Only `from_days` is unstable, and it is unstable on 1.98 too — so pinning the toolchain forward never retires it. **How the error happened**, because it is the same class the file is about: my original probe put both constructors in one source file, got a single `E0658`, and attributed it to both. An error message read as being about more than it was about — written directly beneath a bullet telling the reader to check a suppression's stated reason before trusting it. **Found by the `hevy-mcp` lead**, which hit the same false sentence in its own `src/session.rs` above a `from_secs(30 * 60)`, compiled `from_mins(30)` on 1.93.0 first try, and deleted both of its allows rather than pinning them. **What is actually true here.** `session_store.rs`'s `from_secs(7 * 24 * 60 * 60)` genuinely needs its allow — `from_days(7)` does not compile on either toolchain. The seven over `from_secs(60)`, `from_secs(5 * 60)`, `from_secs(15 * 60)`, `from_secs(30 * 60)`, `from_secs(300)`, `from_secs(1800)` and `from_secs(120)` are suppressing advice that compiles on the MSRV. **Not removing them in this PR.** That is a code change wanting a full gate run, and this PR is the file that was wrong about it. Whoever picks that up should compile rather than trust the new bullet — which now says so, and says that this bullet has itself been wrong once. `unused_async_trait_impl` is unaffected and still needs its allow: it fires on `#[tool_handler]`-generated code and is what puts the lint floor at 1.98. No code, no tests, no gate impact.

jlxq0 added 1 commit

2026-08-26 05:18:29 +00:00

docs: only from_days is unstable, and I attributed one error to two constructors

CI / cargo (pull_request) Successful in 1m46s

Details

CI / docker (pull_request) Has been skipped

Details

438c4927b4

This file said all eleven `duration_suboptimal_units` allows suppress advice
that does not compile, because `from_mins` and `from_days` are "still unstable
on 1.98". Probed separately, one constructor per file, in const context:
`from_mins` and `from_hours` are const-stable on 1.93.0 and 1.98.0, and only
`from_days` is E0658 — on both, so pinning forward never retires it.

The original probe put both constructors in one source file, got a single
E0658, and read it as being about both. An error message attributed to more
than it was about, written into the paragraph directly below one telling the
reader to check a suppression's stated reason before trusting it.

Caught by the hevy-mcp lead, which found the same sentence in its own
`session.rs` above a `from_secs(30 * 60)`, compiled `from_mins(30)` on 1.93.0
first try, and deleted both its allows rather than pinning them.

Only `session_store.rs`'s `from_secs(7 * 24 * 60 * 60)` genuinely needs one.
The other seven over minute-scale constants are suppressing advice that
compiles on the MSRV. Not removing them here: that is a code change wanting a
test run, and this is the file that was lying about it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176noPigX2cwByDtRcafzyi

jlxq0 referenced this pull request

2026-08-26 10:06:24 +00:00

fix(channel): a reply carries what it answers, and a correction arrives as a correction #126

jlxq0 referenced this pull request

2026-08-27 02:01:06 +00:00

docs(agents): why main requires cargo and not docker #131

jlxq0 merged commit f377832ba0 into main

2026-09-02 02:36:53 +00:00

jlxq0 deleted branch duration-claim

2026-09-02 02:36:53 +00:00

jlxq0 referenced this pull request from a commit

2026-09-02 02:36:54 +00:00