Fix StringAnalyzer bug and Add Integer.parseInt

[fa1conn]

When I using InterproceduralConstantPropagationPass, I found a bug in the conditional judgment of StringAnalyzer::analyze_invoke function. It always return false in

if (method == nullptr) {
  return false;
}

So I try to modify it and now it could work normally. And I try to add a conditional judgment to solve Integer.parseInt. After testing it works fine too.

[wsanville]

Can you elaborate more about why there is a bug and what your setup is like? Do you pass android.jar into the invocation to Redex? I am not seeing the results you describe where method == nullptr always gets hit, so I am not entirely convinced a change like this makes sense.

[facebook-github-bot]

Hi @fa1conn!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[fa1conn]

Can you elaborate more about why there is a bug and what your setup is like? Do you pass android.jar into the invocation to Redex? I am not seeing the results you describe where method == nullptr always gets hit, so I am not entirely convinced a change like this makes sense.

Sorry, I didn't know the role of android.jar before. Only remain Integer.parseInt now.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[wsanville]

I don't think the change to Purity.cpp is acceptable, per the definition at 26d0622:

If their outputs are not used, pure method invocations can be removed by DCE.

It would be a mistake for a call to parseInt(), which can throw an exception, to be discarded by dead code elimination if the return value is unused.

[NTillmann]

@wsanville is right, this is going to be a bit more complicated... If we leave the current scheme in place, where constant-propagation only rewrites the results, leaving it to LocalDCE to cleanup the call, then we somehow need to introduce into LocalDCE some notion of conditional purity that depends on the input values.

Being able to compute the result of an invocation (what constant-prop does) isn't necessarily the same as predicting side-effect (and throwing)-freeness (which is what LocalDCE needs).

[wsanville]

Requesting changes per the discussion about the edit to Purity.cpp.