project: honour panicFrames of a profile block #33
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
panicFramesof aprofileblock is read and ignored: whether a native binary prints the frames of a panic is decided by the profile's name (devdoes,releasedoes not), not by the block. The setting should decide.test { coverageThreshold }, the other half of the original title, is split into #191 (it needs an owner decision first).Source
Design (pinned)
CompileProfile.macros()(compiler/src/cli/build.trb) passes the effectivepanicFramesof the project'sprofileblock asTORB_PANIC_FRAMES(1or0);runtime/include/torb.hkeeps frames when it is1, drops them when0, and when the macro is not defined at all falls back to today's rule (TORB_PROFILE_DEVdecides). That fallback is what keeps an older driver and a newer runtime (and the reverse) agreeing.TORB_PROFILE_DEVkeeps deciding the default memory limit and the?return trace;panicFramestouches neither.Acceptance criteria
devbinary built withprofile "dev" { panicFrames = false }prints a panic's site and no frames; areleasebinary built withprofile "release" { panicFrames = true }prints the frames; unset, both behave as today. Covered by a fixture-based test (native panic, expected stderr) for both directions.torb test --native: a failure'sframesfollow the block.dev,release, overridden, workspace-root inherited).emit-cframe tests stay green unchanged).TORB_PANIC_FRAMESundefined behaves exactly as before (runtime/include/torb.hcomment says so).panicFramessentence),docs/tooling/project-trb.mdtable row,docs/standard-library/project.md, the doc comments ofProfileSettingsandProfile, thetorb.hcomment; skills regenerated (build/release/torb.exe docs skill docs skills).Size and routing
One PR, one or two Conventional Commits (
feat(build): honour panicFrames of a profile block,docs(project): ...). Touchescompiler/src/cli/build.trb(andhost.trbif its macro loop needs the setting),runtime/include/torb.h, tests, docs.runtime/and the backend flags are touched, so gates tier A and B. Implementer: Sonnet; the C macro logic is small but gets a diff review.Dependencies
None. The release freeze for 0.1.0 holds PRs until it is lifted; the issue is ready, opening the PR waits for that.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop). Two ignored project settings per PROJECT.md "what is left";
panicFramestouches the runtime frames,coverageThresholdthe test runner. Small to medium, may split. No collision with CONCEPT "Open Questions", no seed impact expected. Release freeze for 0.1.0 (2026-10-06) holds new PRs, next: refine (queued)[loop:torbscript] claim refine by session:loop-torbscript-20261008 until 2026-10-08T14:45:00Z
test { coverageThreshold }(coverage measurement) #191test { coverageThreshold }(coverage measurement) #191test { coverageThreshold }(coverage measurement) #191project: honourto project: honourpanicFramesandtest { coverageThreshold }panicFramesof a profile block[loop:torbscript] refine: ready, split:
panicFramesstays here (precise acceptance criteria, design pinned in the body, seed impact none:TORB_PANIC_FRAMESis an optional macro, an undefined one keeps today's rule, so no two-commit seed dance),test { coverageThreshold }moved to #191 where the owner decision and question q1 are filed (no design record defines coverage). Size: one PR, one or two commits, tiers A and B, Sonnet implementer. next: implement[loop:torbscript] claim implement by session:loop-torbscript-20261008 until 2026-10-08T20:50:00Z
[loop:torbscript] implement: PR #193 open, CI green (bootstrap, tier A incl. the new tests/panic-frames gate, tier B, every host emits the same C), next: review