_unused.MustUse: add optional stack trace capturing#1655
Draft
hcsch wants to merge 2 commits intoamaranth-lang:mainfrom
Draft
_unused.MustUse: add optional stack trace capturing#1655hcsch wants to merge 2 commits intoamaranth-lang:mainfrom
hcsch wants to merge 2 commits intoamaranth-lang:mainfrom
Conversation
The unused MustUse warnings are only emitted with some delay after the
relevant scope with the issue has been left. A single stack frame may
not be enough to correctly identify the source of the issue if for
example an Elaboratable, in common code shared between a few tests, goes
unused based on factors external to the scope it is created and would be
used in.
Python tracemalloc with a depth of at least 3 (in _unused, object creator,
caller) prints a trace, but without function names and with a not
insignificant slowing of execution, listing also locations that are not
helpful to finding the problem.
Optionally capture a stack trace of MustUsed object creation, printing
that alongside the warning to aid in correctly identifying the context
the warning was emitted for.
Setting AMARANTH_TRACE_UNUSED to a truthy value will print a stack trace
filtered for some python/unittest internal locations that are unlikely
to help. Setting AMARANTH_TRACE_UNUSED=full will print an unfiltered
stack trace.
WIP: how this stack trace fits together with the rest of the python
warn_explicit syntax still feels unpolished.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1655 +/- ##
==========================================
- Coverage 91.28% 91.21% -0.07%
==========================================
Files 44 44
Lines 11517 11540 +23
Branches 2242 2246 +4
==========================================
+ Hits 10513 10526 +13
- Misses 842 850 +8
- Partials 162 164 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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
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 unused MustUse warnings are only emitted with some delay after the relevant scope with the issue has been left. A single stack frame may not be enough to correctly identify the source of the issue if for example an Elaboratable, in common code shared between a few tests, goes unused based on factors external to the scope it is created and would be used in.
Python tracemalloc with a depth of at least 3 (in _unused, object creator, caller) prints a trace, but without function names and with a not insignificant slowing of execution, listing also locations that are not helpful to finding the problem.
Whether that makes it worth adding more code for amaranth to do its own tracing I'll leave for you to decide. I admittedly fumbled a bit and managed to believe for a bit that even with
PYTHONTRACEMALLOCset to something greater than 1 I got only one frame printed... not quite sure how, in collecting sample output for this PR I found tracemalloc to produce an okay-ish trace importantly up into the test function that actually caused the issue.Optionally capture a stack trace of MustUsed object creation, printing that alongside the warning to aid in correctly identifying the context the warning was emitted for.
Setting AMARANTH_TRACE_UNUSED to a truthy value will print a stack trace filtered for some python/unittest internal locations that are unlikely to help. Setting AMARANTH_TRACE_UNUSED=full will print an unfiltered stack trace.
WIP: how this stack trace fits together with the rest of the python warn_explicit syntax still feels unpolished.
See GlasgowEmbedded/glasgow#1098 for the context in which I stumbled upon the problem of a warning not being obviously associated with the test that caused it.
Sample outputs from the glasgow PR above (prior to the commit disabling the warning for that glasgow internal file):
Before, no tracemalloc (click to expand)
Before, 3-deep tracemalloc (click to expand)
After, no trace (click to expand)
After, filtered trace (click to expand)
After, full trace (click to expand)