Zygote + SVector is going to be a bit of an adventure. As ToucheSir points out, it’s not designed in, and quite a few rules will do something like call similar & then write into the result. Depending what your function does, you may be able to work around these things.
If your arrays are small enough to use SVectors, then you might be better off with ForwardDiff than Zygote. Especially for Hessians:
julia> @btime ForwardDiff.gradient(A -> bar(A,$B), $A) # was 111.500 μs with Zygote
min 2.000 ns, mean 2.082 ns (0 allocations)
3-element SVector{3, Float64} with indices SOneTo(3):
2.0
4.0
2.0
julia> @btime ForwardDiff.hessian(A -> bar(A,$B), $A) isa SMatrix
min 45.795 ns, mean 46.482 ns (0 allocations)
true
julia> @btime Zygote.hessian(A -> dot(A,$B), $A) isa Matrix # ForwardDiff over Zygote
min 651.235 ns, mean 701.743 ns (7 allocations, 432 bytes)
true
This is certainly the least adventurous solution. You could also investigate using Enzyme, not certain it’ll work but someone may know.
Note that the view here is just a new SVector, it’s been overloaded. You could start providing gradients for such overloaded functions, but there are likely to be quite a few. (And I think this one is a Zygote @adjoint which takes preference over an rrule. So @opt_out may not work.)
julia> view(A,SVector(1,2))
2-element SVector{2, Float64} with indices SOneTo(2):
1.0
2.0
It is possibly to globally fix this, by writing a stricter rule for ProjectTo(::SArray). This won’t fix the use of MVectors etc. inside hand-written rules, but should be able to correct them back to SVectors before being passed to the next rule. How much this will help I’m not certain.