counting and summing Bools with a small integer init promote to Int

[mbauman]

This is a small but concrete and independent change that can easily be split out from #58241 and is required for more pairwise reassociations (like #52397).

Specifically, it's required because count and sum use Base.add_sum, which very intentionally promotes small integers to Int or Uint. And if you add two Bools together, they also promote to Int. But if an init=0x00 is provided, then we get into a strange situation. This is the status quo on master right now:

julia> const +ₛ = Base.add_sum
add_sum (generic function with 4 methods)

julia> (((0x00 +ₛ true) +ₛ true) +ₛ true) +ₛ true
0x04

julia> ((0x00 +ₛ true) +ₛ true) +ₛ ((0x00 +ₛ true) +ₛ true)
0x0000000000000004

In other words, if we happen to choose to re-associate the branches here, we end up with a 0x02 +ₛ 0x02, which promotes to Uint.

This change here adds Bool into the extra promotion behaviors for add_sum. So with this commit, the above session becomes:

julia> (((0x00 +ₛ true) +ₛ true) +ₛ true) +ₛ true
0x0000000000000004

julia> ((0x00 +ₛ true) +ₛ true) +ₛ ((0x00 +ₛ true) +ₛ true)
0x0000000000000004

[mbauman]

OK, so upon reflection here, I think we should just always promote all small integers to Int. In fact, that's what this PR branch Julia (on both current master and this branch!) would do if the mapreduce machinery consistently called reduce_first.

[mbauman]

@nanosoldier runtests()

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

Report summary

❗ Packages that crashed

2 packages crashed on the previous version too.

✖ Packages that failed

14 packages failed only on the current version.

• Package has test failures: 4 packages
• Package tests unexpectedly errored: 2 packages
• Tests became inactive: 1 packages
• Test duration exceeded the time limit: 5 packages
• Test log exceeded the size limit: 2 packages

1240 packages failed on the previous version too.

✔ Packages that passed tests

25 packages passed tests only on the current version.

• Other: 25 packages

5370 packages passed tests on the previous version too.

~ Packages that at least loaded

11 packages successfully loaded only on the current version.

• Other: 11 packages

2975 packages successfully loaded on the previous version too.

➖ Packages that were skipped altogether

920 packages were skipped on the previous version too.

[adienes]

I think Bool seems more Signed-y than Unsigned-y, going off the fact that sign(x::T) == one(T) for all x isa Unsigned, but sign(false) != one(Bool)

so the promotion proposed here would fall out of that and makes sense to me

[LilithHafner]

Triage thinks this is clearly a good idea.

[LilithHafner]

Should we do this with mul_prod, too?

[mbauman]

Should we do this with mul_prod, too?

That's a very good question. I had initially dismissed it without much thought because, well, multiplying by booleans doesn't do much. In fact, there's no need for a widening at all, because the booleans multiply with other types as either their identity or zero. And if we're considering an init, that's gotta be a one of some sort.

But we still have the same (potential) type instability when combining multiple intermediate results as above. prod(ones(10), init=0x1)) won't have the same problem with the returned value, but the exact type is unstable based upon reduction strategy. So yes, seems quite prudent to match the definitions here.