Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A mechanism for diagnostics with context (#42)
## What Changed? Implements a suggestion from #38. Adds the ability to register simple context information, such as the currently executing policy or combinator with the `Context` that is emitted as part of the diagnostics. For instance the named policy `community-safety` in a hypothetical combinator `reaches` would output diagnostics such as: ``` [policy: community-safety] [reaches] Vacuous: no nodes matching starting conditions ``` This is achieved by transparently attaching diagnostic context. First off the `error` and `warning` convenience methods on `Context` still work. Both are now part of the `Diagnostics` trait, The trait is also implemented on `PolicyContext`, which is created by `Context::named_policy()` an transparently attaches the name of the policy to all diagnostic messages emitted from it. It `Deref`s to `Context` so all if its functionality is included. Both `Context` and `PolicyContext` can also create a `CombinatorContext` with the `named_combinator()` method that attaches a combinator name. `CombinatorContext` also `Deref`s to `Context`. ## Why Does It Need To? Right now every diagnostic message has to track where it occurs. By adding this way of accumulating contextual information we can, for instance, have a combinator like `always_happens_before` interrogate itself and dispatch generic diagnostics which are then enriched with contextual information, making them more specific and understandable again. ## Checklist - [x] Above description has been filled out so that upon quash merge we have a good record of what changed. - [x] New functions, methods, types are documented. Old documentation is updated if necessary - [x] A module level documentation section for how to use diagnostic context - [ ] Documentation in Notion has been updated - [ ] Tests for new behaviors are provided - [ ] New test suites (if any) ave been added to the CI tests (in `.github/workflows/rust.yml`) either as compiler test or integration test. *Or* justification for their omission from CI has been provided in this PR description.
- Loading branch information