[pull] master from rust-ndarray:master#1
Open
pull[bot] wants to merge 884 commits intomesalock-linux:masterfrom
Open
[pull] master from rust-ndarray:master#1pull[bot] wants to merge 884 commits intomesalock-linux:masterfrom
pull[bot] wants to merge 884 commits intomesalock-linux:masterfrom
Conversation
Use merge queue
Originally contributed by @messense in pyo3, copied their solution with thanks.
Setup ci so that most checks run in merge queue only
Somehow, these take 30m on powerpc, which is too slow (much slower than anything else.) Try to use s390x instead and run numeric tests in release mode.
We want feedback for contributors from the tests, directly on the PR.
Before, the user could silently violate safety requirements of `SliceInfo::new_unchecked` by directly calling `s![@parse inconsistent_values]`, where `inconsistent_values` represents inconsistent values for the dimensions, etc. Now, the macro calls `SliceInfo::new_unchecked` only in the `($($t:tt)*)` arm, which always constructs the correct values for the call.
Further ci updates - numeric tests, and run all tests on PRs
Fix unsafe blocks in s![] macro
iterators: Re-export IntoIter
Before this commit, running `MIRIFLAGS="-Zmiri-tag-raw-pointers" cargo
miri test test_map_axis` caused Miri to report undefined behavior in
the `test_map_axis` test. This commit fixes the underlying issue.
Basically, Miri doesn't like us using a reference to an element to
access other elements. Here's some sample code to illustrate the
issue:
```rust
let a: Vec<i32> = vec![5, 6];
let first_elt: &i32 = &a[0];
let ptr: *const i32 = first_elt as *const i32;
// Okay: the data is contained in the data referenced by `first_elt`.
let a0 = unsafe { &*ptr.offset(0) };
assert_eq!(*a0, 5);
// Not okay: the data is not contained in the data referenced by `first_elt`.
let a1 = unsafe { &*ptr.offset(1) };
assert_eq!(*a1, 6);
```
Before this commit, we were using `self.index_axis(axis,
0).map(|first_elt| ...)` to create views of the lanes, from references
to the first elements in the lanes. Accessing elements within those
views (other than the first element) led to the Miri error, since the
view's pointer was derived from a reference to a single element.
Thanks to @5225225 for reporting the issue. (This commit fixes #1137.)
Before this commit, running `MIRIFLAGS="-Zmiri-tag-raw-pointers" cargo miri test` caused Miri to report undefined behavior for code using the `WindowsIter`, `ExactChunksIter`, and `ExactChunksIterMut` iterators. This commit fixes the underlying issue. Basically, Miri doesn't like code which uses a reference to an element to access other elements. Before this commit, these iterators wrapped the `ElementsBase` and `ElementsBaseMut` iterators, and they created views from the references returned by those inner iterators. Accessing elements within those views (other than the first element) led to the Miri error, since the view's pointer was derived from a reference to a single element. Now, the iterators wrap `Baseiter` instead, which produces raw pointers instead of references. Although not necessary to satisfy Miri, this commit also changes the `Windows`, `ExactChunks`, and `ExactChunksMut` producers to wrap raw views instead of normal views. This avoids potential confusion regarding which elements are accessible through the views produced by these producers.
Test using cargo-careful
Fix Miri failure with -Zmiri-tag-raw-pointers
Fix Miri errors for WindowsIter and ExactChunksIter/Mut
derived Debug for Iter and IterMut
Add missing safety checks to `From<&[[A; N]]> for ArrayView` and `From<&mut [[A; N]]> for ArrayViewMut`
ndarray-rand crate on the main branch uses the workspace rand and rand_distr versions, which are 0.9 and 0.5 respectively. This commit documents those versions at ndarray-rand's lib.rs' module level.
The current implementation of ArrayRef and its cousins has them as sized types, which turns out to be a critical and unsound mistake. This PR is large, but its heart is small: change the ArrayRef implementation to be unsized. The approach this PR takes is to package the core array "metadata" - the pointer, dim, and strides - into a struct that can either be sized or unsized. This is done by appending a generic "_dst_control" field. For the "sized" version of the metadata, that field is a 0-length array. For the "unsized" version of the metadata, that sized field is a struct. This core type is private, so users cannot construct any other variants other than these two. We then put the sized version into the ArrayBase types, put the unsized version into the reference types, and perform an unsizing coercion to convert from one to the other. Because Rust has no (safe, supported) "resizing" coercion, this switch is irreversible. Sized types cannot be recovered from the unsized reference types.
…1540) Prior to ndarray 0.17, the RandomExt trait exposed by ndarray-rand contained methods for both creating new arrays randomly whole-cloth (random_using) and sampling from existing arrays (sample_axis_using). With the introduction of reference types in ndarray 0.17, users should be able to sample from ArrayRef instances as well. We choose to expose an additional extension trait, RandomRefExt, that provides this functionality. We keep the methods on the old trait for backwards compatibility, but collapse the implementation and documentation to the new trait to maintain a single source of truth.
Signed-off-by: tinyfoolish <tinyfoolish@outlook.com>
* Implement Sync for ArrayParts * Implement Send for ArrayRef --------- Co-authored-by: Jean Commère <jcommere@gaumut.com>
All of these are formatting, linting, etc fixes.
This will allow users to ergonomically compare the two types without over-verbose dereferences. Closes #1549
In preparation for reworking the inner dimension types (see #1506), we'd like to prepare the name `Layout` to be used for new traits and types. Although the type is largely internal (with hidden documentation), we opt for a conservative deprecation approach. In the future, we should consider making `LayoutBitset` entirely internal, but this would require larger changes to the codebase.
In #1479 we used `cfg_attr(docsrs, doc(cfg(feature = "...")))` to add feature-gating information to the documentation. However, this required us to "remember" this at every call site. It turns out that there is a `doc(auto_cfg)` setting that we can use globally to do this for us automatically.
This is a follow-on to #1563; it probably should have been the same PR. In additon to reserving the name `Layout`, we'd also like to clean up the `src/layout` module so that we can pack it full of new features for #1506. So we collapse everything that's currently there into `layout::bitset`, and add a `pub use` declaration to re-export it. As a side note, I'd eventually like `layout` to act as a template for how we handle modules: minimal module-level code and clear module-level documentation. I've made #1566 to track that library-wide.
As we try to release versions more quickly, I'd like to avoid our README looking out of date. I suspect that almost everyone nowadays uses `cargo add` to add dependencies, rather than putting them directly into their `Cargo.toml`, so I've opted to just add a short instruction for installation.
As has been discussed in #1175, I expanded `Zip` for up to 9 producers (including `azip!`, `par_azip!`). Previously, it was only working for up to 6 producers. I also added two simple tests with 9 producers.
Implement phase angle calculation for complex arrays, calculated as atan2(imaginary, real) in radians. Angles are wrapped to (-pi, pi]. --------- Co-authored-by: Adam Kern <akern40@gmail.com>
Tighten linting; fix rustdoc warnings across feature gates I continued using stricter linting and found several odd cases in tests and examples, along with rustdoc warnings triggered by feature-gated items. This commit cleans up those warnings by: - adjusting tests to avoid clippy false positives under -D warnings - removing unused generics and ambiguous empty vec initializers - fixing rustdoc links via feature-gated doc attributes rather than linking to non-exported items All tests are still passing. Clippy still warns about the use of `1..-1` as an empty range; this appears intentional in ndarray slicing semantics, so I’ve left it unchanged for now. Please review the rustdoc changes that rely on feature-gated documentation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )