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

Split up features. #6905

Open
wants to merge 46 commits into
base: trunk
Choose a base branch
from
Open

Split up features. #6905

wants to merge 46 commits into from

Conversation

Vecvec
Copy link
Contributor

@Vecvec Vecvec commented Jan 13, 2025

Connections
Fixes #5247 as this can be infinitely extended (or at least until the stack is exhausted).

Description
Creates an extendable way to use sets of bitflags together. This then splits up features into two subpart: FeaturesWGPU and FeaturesWebGPU. These can be further extended or split if that is needed (e.g shader features vs other features). This is ready for review, tell me if this is the wrong path. I'm quite new to macros (this is probably my second), so tell me if I've missed a helpful feature.

Implementation
Internally this uses a struct as that was the easiest to interact with extendable macros (though externally this interacts with arrays). I think it wouldn't be too hard to switch everything to arrays, but I think it might be slightly messier.

Testing
All existing tests should cover this

Implemented const Functions

  • empty
  • all
  • bits
  • from_bits
  • from_bits_truncate
  • from_bits_retain
  • from_name
  • is_empty
  • is_all
  • intersects
  • contains
  • intersection
  • union
  • difference
  • symmetric_difference
  • complement
  • iter
  • iter_names

Checklist

  • Run cargo fmt.
  • Run taplo format.
  • Run cargo clippy. If applicable, add:
    • --target wasm32-unknown-unknown
    • --target wasm32-unknown-emscripten
  • Run cargo xtask test to run tests.
  • Add change to CHANGELOG.md. See simple instructions inside file.

@Vecvec
Copy link
Contributor Author

Vecvec commented Jan 13, 2025

The diff that the entire thing has made is slightly confusing, I would recommend reading it separately (or at least Basic before Split up Features.).

Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

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

Took a look for a pre-review; looks nice and not as bad, especially if we add some more docs.

wgpu-types/src/lib.rs Outdated Show resolved Hide resolved
@cwfitzgerald
Copy link
Member

Would be interesting to run cargo-semver-checks against this change, might catch any subtleties missed

@Vecvec
Copy link
Contributor Author

Vecvec commented Jan 16, 2025

Would be interesting to run cargo-semver-checks against this change, might catch any subtleties missed

Is that to catch changes to functions? If so it's probably better than my manual check.

Edit: you would have to ignore all the things about bit changes as their size (and type) has changed.

@cwfitzgerald
Copy link
Member

Edit: you would have to ignore all the things about bit changes as their size (and type) has changed.

Yeah, just as a point of information, not a "blocker" kind of thing

@Vecvec
Copy link
Contributor Author

Vecvec commented Jan 16, 2025

If you have it then could you run it? Otherwise, I'm fine to install it and see what it tells me.

@Vecvec
Copy link
Contributor Author

Vecvec commented Jan 17, 2025

Semver-checks seems to think everything is fine. I also removed one of the functions out of the macro and it noticed so it's not just missed it.

@Vecvec
Copy link
Contributor Author

Vecvec commented Jan 25, 2025

Due to all recent changes being docs I think this is ready for review.

@Vecvec Vecvec marked this pull request as ready for review January 25, 2025 08:24
@Vecvec Vecvec requested a review from a team as a code owner January 25, 2025 08:24
Copy link
Member

@Wumpf Wumpf left a comment

Choose a reason for hiding this comment

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

impressive! Almost good to got I think, left some cosmetics comments. But a bit of unit test coverage for the more complex operations (and maybe a sampling of "regular" ones) would be good as well to have!

wgpu-types/src/features.rs Outdated Show resolved Hide resolved
wgpu-types/src/features.rs Outdated Show resolved Hide resolved
wgpu-types/src/features.rs Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
wgpu-types/src/features.rs Outdated Show resolved Hide resolved
Comment on lines +66 to +68
/// Macro for creating sets of bitflags, we need this because there
/// are almost more flags than bits left and the number of flags is increasing.
macro_rules! bitflags_array {
Copy link
Member

@Wumpf Wumpf Feb 2, 2025

Choose a reason for hiding this comment

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

[not really actionable]
initially it took a lot of convincing myself that it's needed to have practically everything inside this macro. After reading the code some more I can see that it's useful, but it pains me not even the struct definition itself is spelled out clearly outside of the macro :(
This is the only place where we need it and I'd rather swallow quite a bit of code duplication for easier to read code here, especially for new-comers. That said, not having to touch everything again if we end up adding a third subdivision is great 👍

Copy link
Contributor Author

@Vecvec Vecvec Feb 2, 2025

Choose a reason for hiding this comment

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

I'm mostly hoping new users will not need to read the macro, I have been trying to make sure all of the customisation is outside it.

Comment on lines 164 to 187
#[cfg(feature = "serde")]
impl WriteHex for Bits {
fn write_hex<W: fmt::Write>(&self, mut writer: W) -> fmt::Result {
let [$($lower_inner_name,)*] = self.0;
$($lower_inner_name.write_hex(&mut writer)?;)*
Ok(())
}
}

#[cfg(feature = "serde")]
impl ParseHex for Bits {
#[allow(unused_assignments)]
fn parse_hex(input: &str) -> Result<Self, ParseError> {
let mut offset = 0;
$(
// A byte is two hex places - u8 (1 byte) = 0x00 (2 hex places).
let cur_input = &input[offset..(offset + (size_of::<$T>() * 2))];
let $lower_inner_name = <$T>::from_str_radix(cur_input, 16).map_err(|_|ParseError::invalid_hex_flag(cur_input))?;
// Two hex chars is a byte.
offset += (size_of::<$T>() * 2);
)*
Ok(Self([$($lower_inner_name,)*]))
}
}
Copy link
Member

Choose a reason for hiding this comment

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

we should add some unit tests at least for more complex operations like these (and fmt etc.) since they're unlikely to be hit by examples and not entirely trivial

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good idea, I've already had trouble with these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Having tests was a good idea, I've started on them and have now realised that they don't print zero value hex places before the start of the actual value.

@Wumpf
Copy link
Member

Wumpf commented Feb 2, 2025

one thing I forgot to do so far is to look at the rustdoc output: We need to make sure that this is all still sane and shows the right things.
We should have a browse over that before merging. Something to look out for is the duplication of all feature flags that is between the "sub flag structs" and the actual Features flag - does it all make sense, or is it confusing thus that we should hide some docs? etc.

@Vecvec
Copy link
Contributor Author

Vecvec commented Feb 2, 2025

Something to look out for is the duplication of all feature flags that is between the "sub flag structs" and the actual Features flag

I could also not re-export wgpu/webgpu features structs to make users have to use wgpu_types::features:: for them while wgpu_types:: for the normal Features. This could also help distinguish them (though if its confusing hiding docs should be first and this second).

@cwfitzgerald cwfitzgerald self-requested a review February 3, 2025 01:51
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.

Plan for When Features overflows u64
3 participants