Test: Child tasks have identical RNG streams after a testset in 1.10.0-beta2

[nhz2]

          So that might be an issue with `Test.guardseed` now then. That `copy` seems to be supposed to work.

Originally posted by @vtjnash in #51225 (comment)

Here is a MWE that works in 1.9 but fails in 1.10.

using Test

@testset "top test" begin
    random_nums = Float64[]
    for i in 1:5
        @testset "inner test" begin
            @test true
        end
        push!(random_nums, fetch(@async(rand())))
    end
    @test !allequal(random_nums)
end

[rfourquet]

This is solved by something like:

@eval Random begin
struct TaskLocalCopy <: AbstractRNG
    xo::Xoshiro
    s4::UInt64
end

function _copy(::TaskLocalRNG)
    t = current_task()
    TaskLocalCopy(Xoshiro(t.rngState0, t.rngState1, t.rngState2, t.rngState3), t.rngState4)
end

function copy!(dst::TaskLocalRNG, src::TaskLocalCopy)
    t = current_task()
    xo = src.xo
    setstate!(dst, xo.s0, xo.s1, xo.s2, xo.s3, src.s4)
    return dst
end

end

And then in Test use Random._copy instead of copy in the implementation of @testset.

The question is: should this be what copy does directly on TaskLocalRNG (instead of calling it _copy), in which case should we bother to implement rand(::TaskLocalCopy) (this feels overkill...) ? It looks like this would address the concerns of #51225.

[nhz2]

I found an example https://github.com/RelationalAI-oss/XUnit.jl/blob/1f422fa22c8f3f570691cd5737990c250f8074b1/test/base-tests.jl#L718-L736 that depends on rand(::TastLocalCopy) being defined, so maybe that is a required method for the thing returned by copy