Calculation suppressFormulaErrors - Minor Breaks

[oleibman]

Fix #1531. Calculation has a property suppressFormulaErrors, which really doesn't work as one might expect. If a calculation throws an exception, the setting of this property might prevent the Exception from being thrown, but it will still trigger an Error. I do not think this makes sense, and will change it so the calculation will return false, which is part of the original design but which would essentially never happen. This allows the user to save a corrupt spreadsheet, but this was already possible through the use of setPreCalculateFormulas(false) on the Writer, so this doesn't really open any new exposures. It nevertheless might be considered a breaking change because of the difference in behavior.

Another break - the visibility of the property is changed from public to private, and a public setter/getter is added.

Although I am enabling this ability, I don't necessarily think it's a good idea to make use of it. See the original issue for a discussion of why. It is not mentioned in the official documentation, and I will not be adding documentation for it. The originator discovered it by reading the code, and I think that is sufficient for what will often be an ill-advised choice.

Many of the large number (unfortunately not quite all) of problems with Calculation.php in phpstan baseline are addressed. Of note are that private arrays phpSpreadsheetFunctions, controlFunctions, comparisonOperators, and operatorPrecedence are changed from static to const.

This is:

- [x] a bugfix
- [ ] a new feature
- [ ] refactoring
- [ ] additional unit tests

Checklist:

• Changes are covered by unit tests
  • Changes are covered by existing unit tests
  • New unit tests have been added
• Code style is respected
• Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• CHANGELOG.md contains a short summary of the change
• Documentation is updated as necessary

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate).
If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

[oleibman]

No interest in resolving Scrutinizer failure. One method needed to add some tests for null in order to satisfy Phpstan; Scrutinizer says these extra checks changed complexity from B to C, which is a failure condition. C'est la vie.

[oleibman]

Phpstan seems to be timing out, for reasons which I do not understand. I may have to cancel this PR and submit another in its place.

[oleibman]

Phpstan failure does not seem to be the result of a botched merge. I will resubmit a less ambitious PR.

[oleibman]

Superseded by 3092. Closing.