I had previously `test_locale` as expected to fail, as it did indeed
fail on my system due to unimplemented functionality. As it happens, it
passes in CI because the locale settings used there (`C`, I believe)
just happen to format integers the same with "%d" as "%n".
I mistakenly un-marked it because I thought I misunderstood the problem.
Technically speaking, my system was misconfigured, leading me to disable
the test in the first place.
`test_locale` calls `locale.setlocale(locale.LC_ALL, '')`, which reads
the value of the `LANG` environment variable and uses that to look up
and reset all the locale settings. My system has `LANG=en_US.UTF-8`,
which is apparently not what this test was expecting. If `LANG` is unset
or set to `C`, the test passes, as it does in CI.
* cformat.rs: refactor fill_string to take fill_with_precision
This allows it to be used with both self.min_field_width and
self.precision, which is necessary for padding out %ds with precision.
* cformat.rs: zero-pad %d entries using precision
This matches CPython's behaviour.
* cformat.rs: don't left-adjust when filling with precision
That will always be prepending 0s to %d arguments, the LEFT_ADJUST flag
will be used by a later call to `fill_string` with the 0-filled string
as the `string` param.
* floats: handle alternate form of general formatting
* cformat.rs: convert width/precision to i32
In CPython, width can be isize but precision can only be i32. Our
implementation currently assumes the same type for both: as CPython's
tests assert on overflows for precision, but not for width, we use that
size for both.
* test_format: run test_common_format
Except for the line which raises an OverflowError in CPython, because
overflows in Rust (and therefore RustPython) abort the process
immediately.
* test_types: don't expect test_float_to_string to fail
Its string formatting usage now works as expected.
