Remove ndims/eltype, and simplify parent type queries.

[maleadt]

Instead of returning the raw typename, provide the full type so that callers can use type variables, if required.
Also provide a version that fully unpeels the array wrapper.
And remove ndims/eltype, which are queries that Base supports already.

These are breaking changes, but needed for JuliaGPU/CUDA.jl#2191 in order to provide the full parent array's typevars (i.e., the buffer type) to the broadcast implementation.

Also fixes #72

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (b50323b) 83.56% compared to head (f9eda78) 93.65%.

Files	Patch %	Lines
src/wrappers.jl	83.33%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master      #75       +/-   ##
===========================================
+ Coverage   83.56%   93.65%   +10.08%     
===========================================
  Files           6        6               
  Lines          73       63       -10     
===========================================
- Hits           61       59        -2     
+ Misses         12        4        -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maleadt]

cc @ChrisRackauckas, I remember you being pretty upset with the previous breaking release of Adapt.jl. This time though, it should only really affect GPUArray.jl/CUDA.jl, so I expect CompatHelper to churn through these pretty quickly.

[ChrisRackauckas]

There's no downstream tests here 😅. @avik-pal can you run some checks? I do think this will be breaking somewhere, but it's different from the last case which cause a subset of things to be possible. This allows more information and thus I don't think that effect is possible this time around, and we just need to bugfix around.

[maleadt]

I did a search on JuliaHub and there's (no) public uses of these unexported, undocumented functions (well, except for GPUArrays, but that's why I've marked this a breaking release). So I'd be surprised, but it's always possible of course.

[avik-pal]

It came from cholesky(::Symmetric{.... CuArray}) being broken, let me trigger the NonlinearSolve CI to confirm

[maleadt]

That will fail, because AFAICT you're not using the updated GPUArrays/GPUArraysCore/CUDA branches. As long as you didn't explicitly call into Adapt.(ndims|eltype|parent), it shouldn't introduce failures.

[avik-pal]

Oh ok, yeah there were no direct calls to that, it was via cholesky