Add support for slicing with inclusive ranges

[jturner314]

Rust 1.26 added support for inclusive ranges, which can be created with syntax start..=end or ..=end.

The behavior of this implementation is a little weird in the rare case that range.end == ::std::isize::MAX due to overflow, but without changing the representation of Slice and SliceOrIndex, I don't see a good way to handle that case cleanly. This shouldn't be a significant issue in practice because:

1. It's rare to have range.end == ::std::isize::MAX.
2. The overflow will result in a panic in debug mode, which is reasonable behavior.
3. In release mode, the overflow will result in slice.end = 0, which will result in a panic when slicing unless slice.start == 0, which will result in an empty slice. The panic is reasonable behavior. The empty slice behavior in the slice.start == 0 case isn't ideal, but I wouldn't expect it to result in any significant problems.

[jturner314]

I just pushed a new version because it turns out that the .start() and .end() methods of RangeInclusive were added only in Rust 1.27, so this PR requires a bump in ndarray's minimum Rust version to 1.27.

[nilgoyette]

Some questions about macros, but apart from that, lgtm.

[nilgoyette]

Another macro question :) From line 499 to 527, would it be possible to create a macro for that? next_dim is implemented for all types of Range except RangeFull.

[jturner314]

Yes, it is a lot more concise with a macro. Thanks!

[nilgoyette]

Line 70 to 129 and 265 to 324. do you think it would a good place for a macro? They are already macros, but it could be a merge of impl_slice_from_index_type and impl_sliceorindex_from_index_type. The only change in all those lines is Slice and SliceOrIndex.

It's a real question btw. Maybe too much macro make the code unreadable or un-fun or wathever. Or maybe the special case From<$index> make this more complex?

[jturner314]

I've merged the macros as you've suggested, which substantially reduced the duplication. The special case is not an issue; I've kept a separate macro for it.

Thanks for pointing this out!

[bluss]

My usual attention for inclusive ranges would be to overflow issues, and I haven't really looked closely enough at that here

[jturner314]

A few notes:

1. I was wrong about the overflow; the result of ::std::isize::MAX + 1 in release mode is ::std::isize::MIN, not zero.

2. An inclusive range with an end of ::std::isize::MAX for slicing is always a user error, so the behavior in this PR is reasonable. (The maximum length of an allocation is Rust is ::std::isize::MAX, so an index of ::std::isize::MAX is one past the maximum possible index ::std::isize::MAX - 1.)

3. I double-checked dimension::do_slice to make sure that even with a weird index value due to overflow, it's not possible to cause unsafe behavior.