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

init_tracker has now a discard function to get single data points back to uninitialized #2081

Merged
merged 2 commits into from
Oct 16, 2021

Conversation

Wumpf
Copy link
Member

@Wumpf Wumpf commented Oct 16, 2021

Connections
Yet another split out of the zero_init (#1688) work
This is how this is going to be used:
cc747bc#diff-1fe34f06c0c0bd67a41a9cb8aa26cae0a2a4b58028ce5e064abb6f8ad23b84cfR264

Description
also:

  • use new standardized partition_point function instead of manual impl
  • remove comment about possible DiscardMemory state, as this is going to be handled differently

Testing
unit testing added

…ack to uninitialized

use new standardized partition_point function
@kvark
Copy link
Member

kvark commented Oct 16, 2021

CI is not happy about the new function

@kvark kvark enabled auto-merge (squash) October 16, 2021 18:05
@kvark kvark merged commit 4af1c31 into gfx-rs:master Oct 16, 2021
@Wumpf Wumpf deleted the init-tracker/discard branch October 19, 2021 19:05
@Wumpf Wumpf mentioned this pull request Oct 24, 2021
Patryk27 pushed a commit to Patryk27/wgpu that referenced this pull request Nov 23, 2022
* refactor: satisfy `clippy::borrow_deref_ref`

* chore: satisfy `clippy::ptr_arg`

* refactor: satisfy `clippy::needless_update`

* chore: `allow(clippy::too_many_arguments)` on `write_output_glsl` test

Since this is test code, I don't think there's a strong impetus to refactor types to consolidate
or otherwise alter arguments here. Let's just `allow` this.

* refactor: satisfy `clippy::single_match`

I think it's sixes whether to keep this code as-is or to `allow(...)` as-is. 🤷🏻‍♂️

* refactor: satisfy `clippy::single_char_pattern`

* refactor: satisfy `clippy::reversed_empty_ranges`

The lint fires because it generally doesn't make sense to use a `Range` built this way; [upstream
`Range` docs]) states:

> It is empty if `start >= end`.

`clippy` wants to help us from naively iterating over a `Range` like this! Thanks, `clippy`!
However, we're not actually using the offending `addresses` variables for iteration. We're using
them as a flat data structure with fields that happen to conceptually match. We can, therefore,
sidestep this lint by "just" inlining into separate variables for start and end instead.

[upstream `Range` docs]: https://doc.rust-lang.org/stable/std/ops/struct.Range.html

* refactor: satisfy `clippy::pattern_type_mismatch`

* chore: `allow(clippy::panic)` for `test`

We definitely should let `panic!(...)` calls exist in `cfg(test)`! It's a very standard way to fail
`#[test]` functions. It seems that previous test authors agree! 😅

* fixup! refactor: satisfy `clippy::pattern_type_mismatch`

* fixup! refactor: satisfy `clippy::single_match`
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