Fix#3900. The code to adjust Decimal and Thousands separators to user-specified choices expects to convert periods to commas and vice versa - hard-coded without taking the user specification into account. This is likely to be the only significant use case, however, as the issue demonstrates, it is not the only possibility. In particular, it will mess up Csv output if decimal separator is kept as period, but thousands separator is set to null string. The code is altered to replace period with the user-selected decimal separator, and comma with the user-selected thousands separator. No existing tests broke as a result of this change in behavior.
This PR resolves about half the statements which we tell Phpstan to ignore. There will still be 23 such annotations spread over 10 source modules for various reasons (too complicated, suspect PhpSpreadsheet code, one Phpstan bug), plus some deliberate errors in the test suite.
Fix#3896. It appears that floating-point arithmetic will give different results in Php 8.4 vs. all earlier releases. This causes tests to fail in the nightly run for ROUNDDOWN, ROUNDUP, and AMORDEGRC. I imagine this won't be the last we hear of this. The failures are a distraction when reviewing PR's. This PR eliminates the distraction by adding in a fudge factor for Php 8.4+ while not changing Php 8.3-. It is not a particularly robust solution, but it should be stable for Php 8.3-, and good enough for Php 8.4+ while I study if a better solution is available.
Phpstan baseline had been reduced to almost nothing, but recently had a big bump in size. Almost all of the increase was due to trait ArrayEnabled, which is easily recoded to avoid the problems.
The samples have become unwieldy when running them from a browser. In particular, the drop-down lists are fixed size with no scrolling, and many of them are now just too large. I have moved all the Calculation samples up a level, and broken several categories (Basic, Chart, DateTime, Engineering, Financial, and Reader) into several pieces.
Convert-Online (now found in the Engineering category) had a number of different problems which are now resolved. It is the only member with any significant code change.
Fix#3875. Even better, fix#2146, which has been open for 2.5 years.
Empty arguments are improperly placed on the stack; in particular, they are added without `onlyIf` and `onlyIfNot` attributes.This results in problems described in 3875.
IF has a somewhat unexpected design. In Excel, `IF(false, valueIfTrue)` evaluates as `false`, but `IF(false, valueIfTrue,)` evaluates as 0. This means that IF empty arguments should be handled in the same manner as MIN/MAX/MINA/MAXA, but you need to be careful to distinguish empty from omitted.
Also note that IF requires 2 operands - `IF(true)` is an error, but `IF(true,)` evaluates to 0.
A continuation of PR #3859. Change code that would be flagged if we were to run Phpstan at level 9 (we currently run level 8). I may or may not follow up with source code (454 level-9 problems remain for src), but there is no reason to avoid the effort for samples.
No changes are made to src.
I check from time to time. There are a number of problems now, mostly due to the elimination of Php 7.4 and replacement of doc-block typing with explicit Php typing.
- Bitwise functions were particularly affected by PR #3718 and PR #3793.
- Chart/Axis and Writer/Xlsx were amusingly affected by PR #3836, which added a scaling option which included an array indexed by the known allowable factors, one of which is 1 trillion, which cannot be represented as an integer on a 32-bit system. Issue3833Test, introduced by the same PR (and not suffering any errors) was expanded to test this value.
- Some minor changes to Reader/Xls and Shared/OLE/PPS to accommodate hex values which are negative in 32-bit but which Php-32 may wind up casting to large floating point numbers; it is not clear to me why these hadn't shown up as problems previously. Possibly this is the result of changes in the most recent Php versions.
- BitAndTest, BitOrTest, BitXorTest and Shared/DateTest were adversely affected by PR #3859 when arguments and/or expected results too large for a 32-bit integer were supplied.
- ImExpTest required a slightly reduced precision for 32-bit. No idea why this hadn't shown up earlier.
Fix#3866. Excel normally treats a missing argument (e.g. `PRODUCT(2,3,)`) as null and ignores it. Not so for MIN/MAX/MINA/MAXA; for those, an empty argument is treated as zero. PhpSpreadsheet is changed to do the same.
oleibman
dependabot[bot]
Adrien Crivelli
Tobias Bäthge