A broken output format on windows?

[zhiburt]

Hi there,

Just noticed that a table seems to be a little bit tricked. I do not certain if this is a windows issue.

You can reproduce it by.

git clone https://github.com/zhiburt/expectrl
cd expectrl
cargo geiger

Functions  Expressions  Impls  Traits  Methods  Dependency

855/3420   6393/25572   1860/7440 0/0     50/200   !  expectrl 0.2.0
0/0        219/219      0/0    0/0     0/0      !  ├── conpty 0.3.0
1223/17405 18323/1389609 823/48930 3/3     114/77943  !  │   └── windows 0.29.0
0/0        0/0          0/0    0/0     0/0      ?  │       └── windows_x86_64_msvc 0.29.0
0/0        34/34        1/2    0/0     2/2      !  └── regex 1.5.4
19/19      678/678      0/0    0/0     22/22    !      ├── aho-corasick 0.7.18
36/37      2067/2140    0/0    0/0     16/16    !      │   └── memchr 2.4.1
0/19       0/319        0/0    0/0     0/30     ?      │       └── libc 0.2.101
36/37      2067/2140    0/0    0/0     16/16    !      ├── memchr 2.4.1
0/0        0/0          0/0    0/0     0/0      :)     └── regex-syntax 0.6.25

[pinkforest]

Thanks for bringing it up :purple_heart:

The column width maximums we use overflow here -

We'll need to improve output formatting to ensure we don't overflow the max column widths in order to keep reasonable max width

I am thinking that instead of for example 1389609 (LOL!) we should just have 1.4M with k/M etc. units shortened to ensure column width guarantees to prevent overflow - given the counter would be 1.4M to begin with.

Another thing we need to do is to count the unsafe's correctly (not sure yet whether this count is valid but makes good test case) for the windows crate - thanks for bringing another test crate subject we can run CI regressions against on next major.

:unicorn: