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
dimsandNbut 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
indssinceNis like under 5 most of the time, recomputing it is cheap.(unlike recomputing
pwhich 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.