Simplify iteration over ranges in general

[haampie]

This complements #27147 with a bit of refactoring of StepRange.

• The step type of AbstractUnitRange is now identical to the element type
• For StepRange{<:AbstractFloat}: assume that we cannot land on the boundary of the range exactly. Assume we can land on the boundary of the range exactly, so that we can always iterate over the full range inclusive without overflows.
• LinRange and StepRangeLen iteration was identical, so they're now combined.

Also fixes a bug where one cannot iterate as follows:

s = 0
for i = typemin(Int) : 1 : typemax(Int)
  i == typemin(Int) + 10 && break
  s += 1
endx
@assert s == 10

[haampie]

Probably the specialization for AbstractFloat can be removed altogether.

> StepRange(1.0, 2.0, 3.0)
ERROR: ArgumentError: StepRange should not be used with floating point

I think it is safe to assume that we will always land exactly on the boundary of the range then? Will update this PR and simplify the iteration even more :).

Edit: done. PR is good to go if the tests are green now.

[haampie]

Just to be sure:
@nanosoldier runbenchmarks(ALL, vs = ":master")

[KristofferC]

@nanosoldier runbenchmarks(ALL, vs = ":master")

Need commit bit.

[KristofferC]

Hmm...

[mbauman]

I think this is a good change, but could we add a ::T assertion here to ensure that we're in line with the step type we report to OrdinalRange?

Edit: whoops, sorry, that is oneunit! It is indeed documented to return T, which is good enough IMO. I had it backwards from one.

[haampie]

Ping @ararslan

[ararslan]

There's nothing in the server log indicative of failure so I'm not sure what the problem was, but I restarted the server anyway.

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[haampie]

Seems like this is good to go then.

[mbauman]

I'm not too worried about a 20% regression in a deprecated method that's already dog-slow, but I am slightly concerned by the 315% regression in ["find", "findprev", "(\"Array{Bool,1}\", \"50-50\")"].

[haampie]

I verified locally that its equal (it generates the same @code_native)

> @benchmark perf_findprev(r) setup = (r = rand(Bool, 10000)) #0961ee3599
  median time:      55.806 μs (0.00% GC)
> @benchmark perf_findprev(r) setup = (r = rand(Bool, 10000)) #eefa333d01
  median time:      55.798 μs (0.00% GC)

Also I think @inbounds or at least @propagate_inbounds is missing in findprev, but that's another issue.

[mbauman]

Great! I confirmed that locally, too. This is good to go.