Completely remove partial linear indexing

[mbauman]

This removes the partial linear indexing deprecation and implents the new behavior: Linear indexing now only takes effect when there is exactly one non-cartesian index.

I know we've typically held off on removing deprecation until the mid-end of the release cycle, but this is a more complicated removal than typical, and several features that I'd like to see in this release depend on or are much simpler with this deprecation gone.

[mbauman]

Hm, interesting. Tests pass in non-debug mode. In gdb on debug mode, I get:

#4  0x00007ffff75eeae2 in check_ambiguous_visitor (oldentry=0x7ffff13af2b0, 
    closure0=0x7fffffffc060)
    at /data/mbauman/julia6/src/gf.c:1129
1129        assert(!jl_subtype((jl_value_t*)sig, (jl_value_t*)type));
(gdb) p sig
$1 = (jl_tupletype_t *) 0x7fffeff3ba90
(gdb) p jl_(sig)
Tuple{typeof(Base.to_indices), Any, Tuple{}}
$2 = void
(gdb) p jl_(type)
Tuple{typeof(Base.to_indices), Any, Tuple{Vararg{Union{Integer, Base.IteratorsMD.CartesianIndex{N} where N}, N} where N}}
$3 = void

Any ideas?

[JeffBezanson]

Looks similar to #21710. I'll take a look.

[JeffBezanson]

#21761

[timholy]

LGTM.

[mbauman]

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

[nanosoldier]

Something went wrong when running your job:

NanosoldierError: failed to run benchmarks against primary commit: failed process: Process(`sudo cset shield -e su nanosoldier -- -c ./benchscript.sh`, ProcessExited(1)) [1]

Logs and partial data can be found here
cc @jrevels

[martinholters]

So the benchmarks apparently make use of partial linear indexing:
https://github.com/JuliaCI/BaseBenchmarks.jl/blob/e3e89ca955ed6af8ba85fea44cb0e81ac0143677/src/array/sumindex.jl#L310-L311

[StefanKarpinski]

Bump.

[mbauman]

Looking through recent BaseBenchmarkReports, it looks like JuliaCI/BaseBenchmarks.jl#106 will be sufficient to fix up the Nanosoldier with this branch.

[mbauman]

Hm, this is ending up with a segfault in one of the codegen tests… I trapped it with gdb but all I can see is that it's ending up trying to access null pagetable0_t somewhere in the GC structures. I'll have to dig into this further next week.

[mbauman]

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

[nanosoldier]

Something went wrong when running your job:

NanosoldierError: failed to run benchmarks against primary commit: failed process: Process(`sudo cset shield -e su nanosoldier -- -c ./benchscript.sh`, ProcessExited(1)) [1]

Logs and partial data can be found here
cc @ararslan

[ararslan]

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

[mbauman]

Yeah, those failures are still expected. I forgot that this depended upon JuliaCI/BaseBenchmarks.jl#106.

[nanosoldier]

Something went wrong when running your job:

NanosoldierError: failed to run benchmarks against primary commit: failed process: Process(`sudo cset shield -e su nanosoldier -- -c ./benchscript.sh`, ProcessExited(1)) [1]

Logs and partial data can be found here
cc @ararslan

[ararslan]

@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

[mbauman]

Thanks so much for shepherding those changes into Nanosoldier, @ararslan! This is looking pretty good now. The FreeBSD failure is in a random fuzzing block within test/ranges.jl — have we seen that before? I managed to reproduce it locally on a different branch by increasing the number of iterations in that loop. I'll try to narrow it down and open an issue.

I'd like to merge this soon.