Prevent type-inferability escaping for rrule of sortslices #817
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In 1.11 something changed i guess with inlining, constant-propagation and/or unrolling.
And now
inds = ntuple(d -> d == dims ? p : (:), N)
doesn't infer.It used to be able to work it out based on constant folding over
dims
andN
but now it gives back a
Tuple{Union{Colon, Vector{Int64}}, Union{Colon, Vector{Int64}}}}
I couldn't workout how to get it to do that again.
But it is so cheap to recompute approprate
inds
sinceN
is like under 5 most of the time, recomputing it is cheap.(unlike recomputing
p
which is not)This at least stops there being a non-bitstype field on the pullback closure.
and contains the inference failure from poluting outside the function.
Together with #816 we should then have 1.11 passing again.