fix(as370): the diagnostic list may be capped, the counts may not (#72) - #85
Merged
Conversation
The nsf370 team cross-checked #84 against their own tree and found as370 reporting two discarded statements in nsfvsvc.asm where four cards are eaten. They read it as #84 having fixed a too-greedy IFO069 bypass. It had not: the decks that module produces under #81 and #84 are byte-identical, so nothing about the joining changed. The cause was the recorder. contd[] held 128 entries and dropped everything past them without a word. nsfvsvc.asm raises 130 continuation diagnostics, and the two that mattered -- `L R3,REQFUNC(,R8)` and `DOUNSTG DS 0H`, both eaten by a comment chain -- are the LAST two. They fell off the end, so a module that discarded four statements reported two, and the severity was decided by whatever happened to fit. That is the exact failure this diagnostic exists to prevent, reintroduced by its own bookkeeping. Every diagnostic is now counted whether or not it is printed, the severity comes from the counters, the printed list stops at 512, and the overflow says so: ... and 89 further continuation diagnostics, 1 of them a discarded statement Measured on the same tree: nsfvsvc.asm now reports all four losses, nsf370's main branch five cards over two modules rather than three. libc370's 743 modules and rexx370 are unchanged, and no deck moves. The other recorders in this file have the same 128-entry shape and the same silence. They are not touched here -- none of them decides a severity the way this one does -- but they want the same treatment.
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
1 participant
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.
The nsf370 team cross-checked #84 against their tree and found as370 reporting
two discarded statements in
nsfvsvc.asmwhere four cards are eaten. Theyread it as #84 having fixed a too-greedy
IFO069bypass.It had not. Measured: the decks that module produces under #81 and under #84 are
byte-identical, so nothing about the joining changed. The cause was my
recorder.
What was wrong
contd[]held 128 entries and dropped everything past them without a word.nsfvsvc.asmraises 130 continuation diagnostics — 126 comment-eats-commentwarnings among them — and the two that matter,
L R3,REQFUNC(,R8)andDOUNSTG DS 0H, are the last two. They fell off the end, so a module thatdiscarded four statements reported two, and the severity was decided by whatever
happened to fit.
That is the exact failure this diagnostic exists to prevent, reintroduced by its
own bookkeeping. It is also the second time today that a silent limit hid a lost
statement.
The change
Every diagnostic is counted whether or not it is printed, the severity comes from
the counters rather than from the array, the printed list stops at 512, and the
overflow is said out loud:
Measured
nsfvsvc.asmlosses reportedmain, cards lost over 2 modulestests/run.shgains the shape that found it: 600 over-long comment cards in onechain, then the statement the chain eats. The printed list is allowed to stop;
the count, the overflow line and the RC 8 are not.
Not fixed here
The other recorders in this file — unknown opcodes, operand errors, over-length
symbols — have the same 128-entry shape and the same silence. None of them
decides a severity the way this one does, so they are less dangerous, but they
want the same treatment. Worth its own issue.