In some cases, even when running in single threaded mode (-j 1), smali
could produce slightly different results if files are not listed in
a consistent order.
This ensures that we assemble a given set of smali files in a consistent
order when running in single-threaded mode, regardless of the order
they are listed in.
The calculation of the number of output registers for
invoke-polymorphic and invoke-polymorphic-range should be based on the
number of registers provided.
These instructions should never be present in a dex file, only in odex/oat
files. However, it's sometimes useful to be able to disassemble an otherwise
valid dex file that happens to contain odex instructions.
This fixes an issue where watches on registers (among other things) don't
work inside a method containing a switch statement, due to a failure
analyzing the method.
In some cases, scope.getProject() may be null. Apparently, IDEA will
automatically pass in the project if you specify one in the constructor.
See, e.g. MigrationElementFinder in the IDEA source.
The newer version has some fixes we need, but we should still ensure
that we can compile against the old version, since that's the version
currently in AOSP.
Previously, we only propagated the conversion if it was a narrowing
conversion, to avoid problems that can occur with member access with
widening conversions.
However, it should be safe to do the conversion for a "sideways"
conversion - one that is neither widening or narrowing.
This can happen if we don't yet have full knowledge of the register types,
or, less likely, if the "true" branch is impossible to reach.
In the first case, we should get better type info as we continue to analyze
the method, and we'll revisit the conversion once we have better type info.
Or, if it really is an impossible conversion, we still want to propagate
the type from the instance-of to the true branch.
