Closed SnoopyLane closed 6 years ago
Merging #26 into master will decrease coverage by
0.02%
. The diff coverage is85.71%
.
@@ Coverage Diff @@
## master #26 +/- ##
=========================================
- Coverage 93.22% 93.2% -0.03%
=========================================
Files 17 17
Lines 2481 2488 +7
=========================================
+ Hits 2313 2319 +6
- Misses 168 169 +1
Impacted Files | Coverage Δ | |
---|---|---|
bytecode/concrete.py | 94.13% <85.71%> (-0.17%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update d3f9470...0954c35. Read the comment docs.
I do not believe this is the right fix see #28
Actually I like yours better.
This fixes #25
to_bytecode() now removes EXTENDED_ARG 0 instructions that appear in the input. These are useless, but can be left behind by ConcreteBytecode.from_code. Removing these from the input prevents analyzers from having to deal with EXTENDED_ARG instructions. Most of them are already removed, and having extras laying around causes failure when converting back to code.
I addition, Python 3.6' dis.stack_effect will raise ValueError when passed EXTENDED ARG, so anybody encountering these instructions must remove them if they wish to convert back to runnable code.
This commit adds a list
deletions
toConcreteBytecode.to_bytecode()
which tracks Instrs to be deleted in new later pass. Processing those deletions is proportional to the number of instructions to delete, not the number of instructions in the Bytecode. I.e. it should be fast for normal code that doesn't have these silly useless instructions.