scanner26.py: make scanner2.py and scanner26.py more alike
scanner2.py: check that return stmt is last in list. (May change)
main.py: show filename on verify error
test/*: add more
Add debug flag to find_jump_targets to show the structure we found.
When there are control-flow bugs, it's often reflected here.
scanner3.py: make code make more similar to 2.x code
- Use xdis 3.0.0 protocol load_module. Needs bump in requirements.txt
and _pkg_info_.py
- Start Python 1.5 decompiling - another round of work is needed to remove
bugs
- small cleanups
As part of tokenization for (de)parsing, we need to do something like a
disassembly, but is is really a little different.
Disassembly, strictly speaking, is done by the xdis module now.
What "ingestion" does is massage the instruction tokens to a form that is
more amenable for parsing.
In sum, ingestion is different than disassembly, although disassembly is
generally the first part of ingestion.
If 2.6 or before POP_BLOCK after a JUMP_IF_FALSE does not
constitute a new statement. The POP_BLOCK is really part
of the JUMP_IF_FALSE. In Python 2.7+ it's a single op.
The scheme for turning 2.6 bytecode into 2.7 psuedo bytecode
I think is a lose.
I won't work for fragment handling.
Instead, change the grammar and syntax rules
This also has the benefits:
* We see how code generation changed over releases
by looking at grammar and semantic rules rather
than arbitrary code
* We can better assocate with what's running
(in a sense this is a restatement of broken fragment
handling)
* With the right structure in place we are in a better position to
handle 2.5, 2.4, etc. That is, after a while, the incremental changes
to get say from python 2.3 bytecode to python 2.7 are great.
Conflicts:
uncompyle6/parsers/astnode.py
Don't try to convert 2.6 bytecode to 2.7 psuedo bytecode.
Instead adjust grammar and semantic actions.
Down the line we should to segregate version changes in
semantic code better.
disas.py:
- disassembles *all* code objects found
scanner*.py:
- no longer need to pass in version numbers; this
is obtained from the class name
- no longer pass in opcodes; this is done at
initialization from the scanner name
- all Pythoin 3 scanners support native disassembly
