Try dumping, when a SPIR-T pass panics, its in-progress spirt::Module
state.
#362
+128
−64
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.
While SPIR-T passes should, in principle, never panic, it can still happen (esp. with WIP code, where e.g.
assert!
s ortodo!()
s might be overrepresented etc.), and before this PR, the partially modified SPIR-T module would be completely lost in the--dump-spirt-passes
output.And because incomplete SPIR-T mutation could result in extremely malformed modules, this PR also wraps the SPIR-T pretty-printing in
std::panic::catch_unwind
, removing one pass' "after" state, at a time, from the pretty-printed versions, while it still panics, and showing an extra warning (with all the pass names that couldn't be printed) if that was necessary at all.Also, there's a minor ergonomic fix in that
after_pass
doesn't need to also be passed the same string asbefore_pass
(sinceSpirtDumpGuard
is tracking it anyway).