126 lines
4.2 KiB
Markdown
126 lines
4.2 KiB
Markdown
# PBS Diagnostics Workshop 4
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the fourth focused discussion for `11. Diagnostics Specification.md` on backend-originated failures:
|
|
|
|
- lowering failures,
|
|
- verifier failures,
|
|
- load-facing failures,
|
|
- and how or whether they map back into the PBS-facing diagnostics contract.
|
|
|
|
## Why This Slice Last
|
|
|
|
This slice should come last because it depends on:
|
|
|
|
- the phase vocabulary,
|
|
- the attribution baseline,
|
|
- and the lowering boundary being clearer.
|
|
|
|
It should be the point where `11` explicitly interfaces with `12`, `15`, and `19`.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm the frontend diagnostics baseline already closed.
|
|
2. Sort backend-originated failure classes.
|
|
3. Decide which backend failures remain PBS-facing diagnostics.
|
|
4. Decide which failures belong only to artifact-facing tooling.
|
|
5. Decide the minimum source-mapping obligations, if any.
|
|
|
|
## Failure Classes To Sort
|
|
|
|
- lowering rejection due to unsupported semantic state,
|
|
- host-binding emission mismatch,
|
|
- verifier rejection of malformed artifact invariants,
|
|
- loader rejection directly attributable to malformed or unauthorized PBS-facing artifact usage,
|
|
- and artifact-only corruption not attributable to valid PBS source.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. The boundary between PBS-facing and artifact-facing diagnostics.
|
|
2. The minimum source-mapping obligation for backend failures.
|
|
3. Whether verifier/load failures participate in `11` directly.
|
|
4. The input contract `13` may assert for these classes.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Only Source-Attributable Backend Failures Enter The PBS Diagnostics Contract
|
|
|
|
Candidate direction:
|
|
|
|
- if a backend failure is directly attributable to validly analyzed PBS source plus normative lowering rules, it remains part of the PBS-facing diagnostics contract,
|
|
- otherwise it is artifact-tool or implementation failure surface.
|
|
|
|
Rationale:
|
|
|
|
- This keeps PBS diagnostics user-facing rather than compiler-internal.
|
|
|
|
### 2. Verifier And Loader Failures Enter `11` Only When Userland Actionability Exists
|
|
|
|
Candidate direction:
|
|
|
|
- malformed or unauthorized host-facing artifact usage attributable to source remains in scope,
|
|
- purely artifact-internal corruption or implementation bugs remain out of scope.
|
|
|
|
Rationale:
|
|
|
|
- This matches the current draft's narrow load-facing baseline.
|
|
|
|
### 3. Source Mapping Is Useful But Minimal In v1
|
|
|
|
Candidate direction:
|
|
|
|
- v1 requires a source-facing location when the failure is source-attributable,
|
|
- but does not yet require one standardized artifact offset map or source-map format.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the contract implementable while leaving room for richer tooling later.
|
|
|
|
### 4. Conformance Should Assert Only The Stable External Surface
|
|
|
|
Candidate direction:
|
|
|
|
- `13` may assert rejection phase, source attribution, and rejection class for backend-originated PBS diagnostics,
|
|
- but not one exact verifier or loader message format.
|
|
|
|
Rationale:
|
|
|
|
- This keeps conformance aligned with the rest of `11`.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Which lowering failures are legitimate user-facing diagnostics versus compiler bugs?
|
|
2. Do verifier failures need their own normative phase label, or map into linking/load-facing rejection?
|
|
3. Is one source location enough for backend-originated failures?
|
|
4. How much of artifact-facing tooling belongs in the PBS language contract at all?
|
|
5. What exactly must `13` be able to test once `12` and `15` are closed?
|
|
|
|
## Expected Outputs
|
|
|
|
This workshop should produce:
|
|
|
|
1. a decision record for backend diagnostics boundaries,
|
|
2. a source-mapping obligations note,
|
|
3. and explicit integration tasks for `11`, `12`, `13`, and `15`.
|
|
|
|
## Explicit Deferrals
|
|
|
|
- exact source-map file formats,
|
|
- artifact UI presentation,
|
|
- implementation bug reporting policy,
|
|
- and internal compiler exception handling.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/11. Diagnostics Specification.md`
|
|
- `docs/pbs/specs/12. IR and Lowering Specification.md`
|
|
- `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
- `docs/pbs/specs/19. Verification and Safety Checks Specification.md`
|
|
- `docs/pbs/agendas/11. Diagnostics Agenda.md`
|
|
- `docs/pbs/agendas/11.1. Diagnostics Workshop 1 - Diagnostic Identity and Attribution.md`
|
|
- `docs/pbs/agendas/11.3. Diagnostics Workshop 3 - Cost Diagnostics and Warning Policy.md`
|
|
|