Add error catalog documentation#254
Merged
Merged
Conversation
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
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.
AI Summary
This PR adds a new error catalog to the CGP knowledge base: a fifth top-level documentation section, under
docs/errors/, that documents the compiler errors CGP produces after a macro has expanded, organized by the kind of error a user sees rather than by the macro that produced it. It is a documentation-and-tests change only — no library crate, proc-macro, or runtime code is touched, so CGP's behavior is unchanged. The diff spans 49 files (+1582/−95): eleven new files establish the catalog, one new sub-skill teaches an agent to extract errors, several existing documents are rewired to point at the catalog, and the compile-fail test suite gains the fixtures that back the newly documented classes.The work is deliberately incremental. This PR builds the catalog's framework and writes its first nine error classes; it does not finish migrating every failure-mode note out of the per-macro implementation docs. The catalog's README tracks which classes are done, and until a class is migrated its fixture keeps its old cross-link, so the two documentation systems stay consistent during the rollout.
High-level concepts
The catalog exists because a CGP macro expands to ordinary Rust, so most mistakes are not caught by the macro — they surface later, when the compiler type-checks the generated code, in diagnostics shaped by CGP's machinery in ways that are hard to read. A single mistake deep in a dependency graph can print a wall of errors naming generated types the user never wrote, and the true cause is often buried or suppressed entirely. The catalog names and maps these post-codegen failures so a reader can recognize a class on sight and know what to do about it.
The central organizing idea is the hidden-versus-surfaced axis: whether the compiler's diagnostic actually contains the root cause of a failure. When broken wiring is forced through a check trait —
check_components!assertingCanUseComponent, which walksIsProviderFor— the compiler evaluates the provider'swhereclause and surfaces the concrete missing bound. When the same broken wiring is instead exercised by calling the consumer-trait method directly, the compiler sees the consumer trait's blanket impl among the candidates, finds it inapplicable, and falls back to a heuristic that reports only "the method's bounds were not satisfied" — hiding the dependency that actually failed. The same mistake therefore produces two completely different diagnostics, and the catalog isolates the hidden classes so a reader knows not to hunt for a cause that is not there.A second recurring difficulty the catalog addresses is verbosity: because wiring is lazy, one unmet dependency surfaces at every provider that transitively needs it, so the compiler prints one error block per affected provider even though there is only one thing to fix. The catalog teaches that the error count reflects the depth of the dependency graph, not the number of mistakes, and shows how to find the single concrete-item block among the repeats.
The catalog is written for three readers at once, which is what distinguishes it from a debugging tutorial. The first is a future
cargo-cgptool author who needs a complete map of which classes hide the root cause and where it sits before a post-processor can decide what to extract, suppress, and re-present. The second is an agent debugging CGP code, here or in any downstream project. The third is an error-extraction sub-agent that reads a long error on the main agent's behalf and returns only its compact anatomy. Because all three need the same few facts — the class, whether the root cause is present, and its position — every document records exactly those and, as a firm rule, never pastes verbatim compiler output.Finally, the catalog inherits CGP's existing acceptable/problematic/rejection split to decide where each failure is documented. An acceptable failure — one CGP intentionally defers to the compiler because it lacks a whole-program view — is documented here in full. A problematic failure — a CGP defect — has its observable error cataloged here while the explanation of why it is a defect stays under the owning macro's Known issues. A failure a macro catches by rejecting its input is not cataloged here at all; it stays with the macro. This keeps the catalog the canonical home for post-codegen compile-fail fixtures without duplicating or losing information.
The nine documented classes
The catalog is split into three subdirectories by the axis above, and this PR populates each. The
hidden/directory holds the one class whose diagnostic suppresses the cause. Thechecks/directory holds the classes where a check surfaces the cause, plus the volume-dominated cascade. Thewiring/directory holds the whole-program structural failures with definite error codes.The classes written in this PR are the following. In
hidden/: unsatisfied dependency (E0599/E0277), the hidden case where a direct method call reports only that the method's bounds are unmet. Inchecks/: check-trait failure (E0277), its surfaced twin where a check names the concrete missing bound in ahelp:note; verbose dependency cascade, one deep mistake reported at every dependent provider; and unregistered namespace path (E0277), a#[prefix]redirect that lands on a path no entry binds. Inwiring/: conflicting wiring (E0119/E0428), a key or name wired twice; orphan-rule violation (E0210/E0117), a prefixed#[default_impl]registered from the wrong crate; wiring cycle (E0275), aUseContextdelegation that chases its own tail; namespace inheritance cycle (E0275), a circular parent chain caught eagerly at thecgp_namespace!definitions; and unconstrained generic (E0207), a per-entry generic that never reaches the key. Each document follows one fixed shape — what triggers it, the diagnostic, where the root cause is, resolving it, notes for tooling, backing fixtures, and related links — so a reader can navigate any of them by habit.Structural changes
Beyond the new catalog directory, the PR rewires the surrounding knowledge base so every path into these errors now leads to the catalog. The structural changes are these.
docs/errors/section. Eleven new files: aREADME.md(the catalog's overview and index), anAGENTS.md(its authoring rules), and nine class documents across thehidden/,checks/, andwiring/subdirectories.docs/skills/cgp/references/error-extraction.mdteaches an agent to reduce a long CGP error to a compact summary and, crucially, to delegate the reading to a sub-agent so a wall of generated-type errors never floods the main context. It is registered in the/cgpskill's router (SKILL.md).docs/README.mdanddocs/AGENTS.mdare updated to introduce the errors directory, state the dividing line with the rest of the base (compiler-raised failures live here; macro-rejected input stays with the macro), and note the class-by-class migration.docs/implementation/entrypoints/documents (cgp_component,cgp_impl,cgp_namespace,check_components,delegate_and_check_components,delegate_components) have their## Failure modesprose replaced by short cross-links to the catalog class, while retaining what the implementation doc uniquely owns — the error-span mechanics and, for a defect, the Known-issues explanation.docs/guides/debugging.mdgains a newE0599"hidden" entry, expands theE0277entry to coverCanUseComponentand namespacePathConslookups, links every error-code entry to its catalog class, and flags the compiler's "increase the recursion limit" advice as wrong for a true cycle.docs/reference/macros/cgp_namespace.mdexpands its Known issues with the unregistered-path and inheritance-cycle failures and the bare-keyfor-loop overlap;docs/implementation/AGENTS.mdrecords the migration policy;crates/tests/AGENTS.mdadds a rule to keep fixture subdirectories small (nest-split past ~a dozen) and to catalog post-codegen fixtures indocs/errors/..stderrback the newly documented classes —use_context_cycle,inheritance_cycle,unregistered_prefix_path,for_loop_bare_key, anddependency_cascade— and nine existing fixtures have their header comments re-pointed from the implementation docs to the catalog class they exercise.Impacts
The changes ripple out to documentation structure, the test suite, and how agents work, without touching any shipped code. The concrete impacts are the following.
for-loop overlap, and the six-block dependency cascade are now pinned by.stderrsnapshots, so a regression in any of these diagnostics changes a fixture. Verification iscargo nextest run -p cgp-compile-fail-tests, and the.stderrfiles are toolchain-pinned (regenerate withTRYBUILD=overwrite).crates/tests/AGENTS.mdanddocs/errors/AGENTS.mdnow enforce./cgpskill an explicit "hand a long error to a sub-agent, act on the summary" pattern and the hidden-versus-surfaced shape knowledge, so agents stop reading cascades inline or chasing a cause a hidden error does not contain.Verification note
Because the change is confined to Markdown documentation and
trybuildfixtures, there is no runtime surface to exercise; the meaningful check is that the new and existing compile-fail fixtures still fail to compile with the pinned diagnostics, viacargo nextest run -p cgp-compile-fail-tests. This report describes the committed state of theerror-catalogbranch relative tomain; the fixtures were not re-run as part of writing it.