* Real Errors Identified in Calculation by Scrutinizer
Before Scrutinizer broke, I took a look at the remaining 43 errors which it categorized as 'major'. Most of these were false positives, but, in the case of Calculation and Reader/Xlsx/Chart, I was able to determine that its analysis of some of the problems was correct. There is little point addressing the false positives until it starts working again, but we should fix the real errors.
This PR addresses the real errors in Calculation.
- A test for `$pCellParent` should have been a test for `$pCellWorksheet`.
- A test for `$operand1Data['reference']` should have been a test for `$operand1Data['value']`.
- A test for `$operand2Data['reference']` should have been a test for `$operand2Data['value']`.
* Fix Attempt to Erroneously Call trim on Array
Fix#2780. Warning message is being issued when getting calculated value of cell with value `=INDIRECT(ADDRESS(ROW(),COLUMN()-2))/$C$4`. This appears to be the case for all recent (and probably not so recent) releases; it is not a result of changes to the code base. Fix added to this PR because the erring section of code was proximate to code already changed in the PR. Test added.
* Minor Code Changes
Apply some suggestions from @MarkBaker
PHP 8.2 is supposed to deprecate the use of `['self', 'functionname']` for callables, suggesting the use of `[self::class, 'functionname']` instead. We made this change in a recent PR, and, while I'm thinking about it, I'll fix the remaining 2 modules with this construction. Vlookup is already adequately covered in unit tests. Reader/Xls/MD5 is not; a unit test is added.
Before Scrutinizer broke, I took a look at the remaining 43 errors which it categorized as 'major'. Most of these were false positives, but, in the case of Calculation and Reader/Xlsx/Chart, I was able to determine that its analysis of some of the problems was correct. There is little point addressing the false positives until it starts working again, but we should fix the real errors.
This PR addresses the real errors in Reader/Xlsx/Chart.
- An assignment to `$XaxisLable` should be an assignment to `$XaxisLabel`.
- An assignment to `$YaxisLable` should be an assignment to `$YaxisLabel`.
Fixed that bug, using a slightly faster algorithm for the sort index than the simple fix would have used, and modified the tests that didn't have the correct expected result :-(
- TEXTBEFORE – Returns text that’s before delimiting characters
- TEXTAFTER – Returns text that’s after delimiting character
- TEXTSPLIT – Splits text into rows or columns using delimiters
- VSTACK – Stacks arrays vertically
- HSTACK – Stacks arrays horizontally
- TOROW – Returns the array as one row
- TOCOL – Returns the array as one column
- WRAPROWS – Wraps a row array into a 2D array
- WRAPCOLS – Wraps a column array into a 2D array
- TAKE – Returns rows or columns from array start or end
- DROP – Drops rows or columns from array start or end
- CHOOSEROWS – Returns the specified rows from an array
- CHOOSECOLS – Returns the specified columns from an array
- EXPAND – Expands an array to the specified dimensions
Fix#2768. DateFormatter handles only one of six special formats for time intervals `[h] [hh] [m] [mm] [s] [ss]`. This PR extends support to the rest. There should be no more than one of these in any format string. Although it certainly could make sense to treat `[d] [dd]` in the same manner, Excel does not seem to support those.
Interesting observations - hours and minutes are truncated (presumably because they may be followed by minutes and seconds), but seconds are rounded. Also, there are some floating point issues, which fortunately showed up for the example in the original issue. There, the time interval was 1.15, which should evaluate to a minutes value of 1656 (as it does in Excel). However, on my system it evaluated to 1655 because of a rounding error in the 13th decimal place. To overcome this, values are rounded to 10 decimal places before truncating.
Extract tryDefinedName logic from Worksheet, nd move into the Worksheet/Validations class as a public static method
Apply stricter validation to autofilter range arguments
I suspect that scrutiniser may complain that the pass-by-reference values in an expression like `sscanf($coord, '%[A-Z]%d', $column, $row)` don't exist; but PHP handles that without issue, creating the variables as needed, and phpstan has no problems with that, so scrutiniser shouldn't treat it as an issue. There's no point in adding code (even if it's just pre-defining call-by-reference arguments) when it's unnecessary overhead.
MarkBaker
Mark Baker
dependabot[bot]
oleibman
aswinkumar863
aswinkumar863