Simplify s![]

[CAD97]

Fixes #1194 with a very slight generalization to make this arm more similar to the other arms.

[bluss]

what's the impact on the unsafe code block here?

[CAD97]

It's still necessary, as SliceInfo::new_unchecked is unsafe.

Technically, this means that someone using the macro could write

s! { @parse
    {
        // statements in an unsafe context
        ::core::marker::PhantomData::<::ndarray::Ix0>
    },
    ::core::marker::PhantomData<::ndaray::Ix0>,
    []
}

to get an unsafe context without writing unsafe, but this is an internal rule, so that's not too worrisome. However, it is reasonable to evaluate the arguments outside of the unsafe block just for thoroughness.

[jturner314]

Thanks for bringing this up. Some of the other @parse arms had safety issues if called directly. I've created #1196 to fix that. With that change, we can change this PR to modify the "empty case" arm to the following:

    // empty call, i.e. `s![]`
    (@parse $in_dim:expr, $out_dim:expr, []) => {
        {
            debug_assert_eq!($in_dim, ::core::marker::PhantomData::<$crate::Ix0>);
            debug_assert_eq!($out_dim, ::core::marker::PhantomData::<$crate::Ix0>);
            (
                [],
                ::core::marker::PhantomData::<$crate::Ix0>,
                ::core::marker::PhantomData::<$crate::Ix0>,
            )
        }
    };

This is safe, since it always expands to valid values for the SliceInfo::new_unchecked call (which is in the ($($t:tt)*) arm with #1196). It has debug assertions to ensure that $in_dim and $out_dim are the expected values. (They'll always be the expected values, unless the user calls s![@parse ...] directly.

[CAD97]

Check failures are

• unrelated (new clippy warning)
• spurious docker error?

  docker: Error response from daemon: Duplicate mount point: /home/runner/work/ndarray/ndarray.

[bluss]

I'm sorry this has now been conflicted by other changes, so I'll close this for now. I'm not sure about the simplification, the old version makes sure the dimensions are really Ix0 (empty) for the empty slice, and this one doesn't have the same effect? Not sure.

[CAD97]

It doesn't, tbf. The main reason I made the PR is that $crate in macro patterns is pretty cursed.