fix: very simple constant propagation for obvious cases

[jeshecdom]

Issue

Closes #716.

This is a simplified version of the AST-based constant propagation algorithm in PR #852 in order to have a quick fix for the issue. It solves very obvious cases of division by zero, null de-reference and integer overflow. The analysis tries to execute expressions and statements until it reaches a join point of two or more branches. At that moment, it stops. The analysis does not carry out branch joining or fix-point computation.

For example, it is able to detect the division by zero in this:

fun test(v: Int): Int {
   let a = 10;
   let x = v + 1;
   if (a >= 10) {       // Condition known at compile-time, so, no branching involved.
      x = v;
      a = 5;
   } else {
      a = v;
   }
   return 1 / (a - 5);   // Division by zero
 }

But not in here:

fun test(v: Int): Int {
  let a = 10;
  let x = v + 1;
  if (v >= 10) {   // Branching: cannot determine condition at compile-time.
     x = v;
     a = 5;
  } else {
     a = 5;
  }
  return 1 / (a - 5);   // No division by zero detected, since it cannot join paths (FunC detects the error)
}

If needed, we could get it closer to the code in PR #852 by later incremental additions. This PR replaces PR #852.

NOTE: This solution is intended to be temporary until proper constant propagation is implemented.

Checklist

• I have updated CHANGELOG.md
• I have added tests to demonstrate the contribution is correctly implemented: this usually includes both positive and negative tests, showing the happy path(s) and featuring intentionally broken cases
• I have run all the tests locally and no test failure was reported
• I have run the linter, formatter and spellchecker
• I did not do unrelated and/or undiscussed refactorings

[anton-trunov]

tests cannot be deprecated: these are our specification, so when you switch to a proper implementation, tests should still pass

[anton-trunov]

What will we need to change in the codebase to switch to a more advanced solution?

[jeshecdom]

What will we need to change in the codebase to switch to a more advanced solution?

Depending on what we want to do with constant propagation:

• For just detecting errors: I could keep adding code for path joining and fixpoint computation, which is available in the closed PR Simple constant propagation AST-based analysis #852 . That code just needs adapting, because of the several refactors the codebase has went through. However, there is one big change: I would need to adapt the interpreter so that it can work with arbitrary lattice values and this is tricky for structs. I haven't thought the details though, at this moment is just a hunch. I handled that problem in the closed PR Simple constant propagation AST-based analysis #852 with several hacks, but the main one was to wrap the environment stack class with a class that handles lattice values (I do not like such solution).

• Additionally, for optimizing code: This one is harder to predict. I can predict the initial changes that would be required with more confidence.

  • Add the optimization phase as a separate phase (currently tentative in PR refactor: add optimization phase #1047).
  • The transformation of AST to CFG would probably not require changes to the codebase. However, there is a potential point that could impact it, but I am not sure: handling the SrcInfo of the nodes produced during CFG transformation.
  • I would need to adapt the interpreter so that it handles arbitrary lattice values, as in the "just for detecting errors" case.
  • The actual algorithms for computing the fixpoints I think would not require changes to the codebase.
  • For sending the CFG back into an AST I still do not have a clear image on how to do that, so I am not sure if this would make a codebase impact.... probably not, but it is just a hunch.

[i582]

LGTM

[i582]

LGTM