Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add trait for linear allocation to enforce use of LinearAllocator at compile-time #188

Merged
merged 3 commits into from
May 19, 2024

Conversation

ian-h-chamberlain
Copy link
Member

Also convert ndsp::Wave to be generic over any linearly-allocated type so that callers could use Vec etc. if they wanted.

This will also be useful for citro3d-rs, e.g. https://github.com/rust3ds/citro3d-rs/pull/42/files#r1477434491

convert ndsp::Wave to be generic over any linearly-allocated type so
that callers could use Vec etc. if they wanted.
@ian-h-chamberlain ian-h-chamberlain self-assigned this May 17, 2024
@ian-h-chamberlain ian-h-chamberlain requested a review from a team as a code owner May 17, 2024 18:45
@ian-h-chamberlain ian-h-chamberlain changed the title Add trait for linear allocation Add trait for linear allocation to enforce use of LinearAllocator at compile-time May 17, 2024
This is stable in 1.78 but not in our pinned nightly, so just add the
feature flag for now.
Copy link
Member

@Meziu Meziu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great addition. This looks like it might help easing some of the friction that was found when implementing memory requirements in citro3d (and might be a long term helping hand in ctru-rs as well).

ctru-rs/examples/audio-filters.rs Outdated Show resolved Hide resolved
ctru-rs/examples/audio-filters.rs Show resolved Hide resolved
ctru-rs/src/linear.rs Show resolved Hide resolved
ctru-rs/src/linear.rs Outdated Show resolved Hide resolved
@@ -23,6 +23,7 @@
#![feature(try_trait_v2)]
#![feature(allocator_api)]
#![feature(new_uninit)]
#![feature(diagnostic_namespace)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feature is stable, there is no need to add it to the list.

Copy link
Member Author

@ian-h-chamberlain ian-h-chamberlain May 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately it's not stable yet in the pinned compiler version we have... I could raise the rust-version in our crate to 1.78 and bump the pinned nightly, if you think that's preferable?

Edit: actually, tried this but it won't work unless we update to a very recent nightly that contains rust-lang/rust#124649
My preference would probably be to leave it with #![feature] for now, but could still go either way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right. I'm for the idea of "if we use an unstable feature, we should update the MSRV as soon as it is stabilised" since stability is the biggest reason I see why we should bump the MSRV.

Still, for such a small thing it isn't necessary. We can bump it later down the line whenever we see fit.

AsRef<T> accepts more types than Deref<Target = T>, so it makes sense to
be compatible with more types if possible.

Also make LinearAllocation an unsafe trait instead of sealing it, so
that downstream users can implement it if they want.
@ian-h-chamberlain ian-h-chamberlain merged commit 7e0be08 into master May 19, 2024
4 checks passed
@ian-h-chamberlain ian-h-chamberlain deleted the feature/comptime-alloc-check branch May 19, 2024 01:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants