Add a 'safe' or similar command-line flag

[arporter]

Finding out where things are going wrong when using PSyclone to process existing code can be hard. It is proposed to add a --safe flag or similar akin to -O0 on a compiler. This will turn off things that we know can be problematic, e.g.:

• Ensure no transformations are applied
• Disable canonicalisation
  • e.g. put multi-statement WHERE constructs into CodeBlocks (or just all WHERE statements?)
  • CASE statements
• Disable line-length limiting?

There are probably other things. Suggestions from @hiker, @TeranIvy, @sergisiso and @LonelyCat124 are welcome!

[arporter]

I've (perhaps optimistically) given this the 'good-first issue' - at least adding the command-line flag and populating something in the Config object should be reasonably straightforward (as much as anything ever is).

[arporter]

We may want to support selectively turning-off the various things I listed in the original description. Therefore the precise form of the command-line flag needs some thought.

[LonelyCat124]

I think --safe as a "turn on all of these options" is a good idea (with its help flag saying what it turns on, similar to how -O3 turns on e.g. -ffast-math and -floop-unrolling and etc. etc.) and having various other options as things that can be turned on/off one-at-a-time to check where the disparity comes from between --safe and a standard execution of PSyclone.

[sergisiso]

I understand the point of "safe" for the frontend (we do some cannonicalisations that can fail and have some ambiguities coming from fparser; and we have do way to disable/stop them), but I don't think we need to do:

• Ensure no transformations are applied
• Disable line-length limiting?

The can already do these by changing flags (no -s -> no transformations), and would will make the "safe" functionality very complex if it is more broad than the front-end.

[LonelyCat124]

I think if these are already flags (e.g. -s /dev/null and -l unlimited or something) having the psyclone entry point part of --safe just override any other values for these flags could be a straight-forward solution to enable those.

[sergisiso]

But if it overrides the values we can not try things like "safe frontend but with transformations enabled" or "safe frontend but with line length limits enabled" which can help identify exactly what produces the issues:

psyclone --safe -l off ...  # with no transformation and no line limits
psyclone --safe -l off -s transform.py ... # with transformation and no line limits
psyclone --safe -s transform.py ... # with transformation and line limits
psyclone -s transform.py ... # all enabled

[LonelyCat124]

Yeah, i think my idea was more

psyclone --safe .... # Fully safe
psyclone -l off -s transform ... # Transform enabled, WHERE statements transformed, no line limits
psyclone --nowhere -s transform # Transform enabled, WHERE enabled, line limits

so safe is just a superceded set of flags and once safe works you have a set of flags you can remove one at at time until things break. I do like your idea though as it makes it easier to re-enable bits individually (but requires users to correctly remove flags to use --safe). We could have --safe as full override and a separate flag to add any safe flags not overridden? But gets a bit complicated.

[arporter]

Could we have something like:

psyclone --safe=all
psyclone --safe=nowhere,no_stmt_fns

I take your point about the line-length limiting etc. Perhaps the rule should be that if an option can already be controlled by a flag then it should not be part of 'safe' (although we could print a warning if e.g. --safe is used in conjunction with -s)?

Perhaps we should draft a 'Troubleshooting' section of the User Guide. That will help us think this through.