hardware_buffer_format: Add catch-all variant #407
Conversation
spencercw
force-pushed
the
hardware-buffer-format-catchall
branch
from
d170da5 to
23c8576
Compare
|
The MSRV issue is a bit unfortunate. Seems explicit discriminants on enums with fields is only supported as of Rust 1.66 (Dec 2022). Is it ok to bump the MSRV? |
spencercw
force-pushed
the
hardware-buffer-format-catchall
branch
from
23c8576 to
ef887d8
Compare
|
I'd rather panic and extend the crate in this case. Is this a real problem right now or are you anticipating a future problem? |
|
This is a real problem right now. I am creating an |
|
Sure, then we need an I'll think about the MSRV bump for a bit: this'll be used by |
Note also that this PR makes it impossible to use EDIT: On that note if |
I think we're currently at 1.65 in some crates (GATs addition). The WGPU rust version is 1.65, so not sure about the bump yet. |
|
The only way I can see to drop the discriminants would be to rely on the default numbering (i.e., first entry is I don't mind sitting on this one for a while. Sounds like a 1.66 MSRV can't be too far off. |
Yeah, because it needs these discriminants to generate a (Otherwise the implementation for |
|
Sounds like a reasonable idea for |
|
It's more so that I don't have a clear overview of what's needed now, but we might as well ditch the macros and implement |
|
That could work, although unless I'm missing something obvious, I can't see any custom |
spencercw
force-pushed
the
hardware-buffer-format-catchall
branch
from
ef887d8 to
5ddde16
Compare
|
Added manual |
Turns out it was a custom function instead (otherwise it'd have to be a Note that |
spencercw
force-pushed
the
hardware-buffer-format-catchall
branch
from
5ddde16 to
382c717
Compare
|
Ok that makes sense. I've applied those changes. |
There was a problem hiding this comment.
Bit unfortunate that we cannot use enum discriminants anymore (and have manually write out the conversion both ways...), but as discussed that's not really possible unless we add yet another wrapper type (or getter) to struct HardwareBufferDesc to represent unknown variants (besides more actively updating this enumeration with unreleased constants...).
Asking @rib for another review.
spencercw
force-pushed
the
hardware-buffer-format-catchall
branch
from
382c717 to
69af199
Compare
Hardware buffers can have private formats which don't appear in the NDK header. Add a catch-all variant to avoid panicking in `HardwareBuffer::describe()`.
spencercw
force-pushed
the
hardware-buffer-format-catchall
branch
from
69af199 to
74d06f3
Compare
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts #407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts #407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts #407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts #407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts #407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts #407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts #407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
It is older than 6 months and now required for the `toml_edit` dependency (used by `num_enum_derive`). At the same time `num_enum` relies on arbitrary enum discriminants (for discriminated enums with tuple/struct variants) introduced by Rust 1.66 in order to implement `#[num_enum(catch_all)]`. This feature comes in use to replace the manual `match` blocks when implementing conversions for `HardwareBufferFormat` when also having an `Unknown(u32)` to catch valid private/vendor values that won't ever be described inside the NDK. This change effectively reverts rust-mobile#407 to its initial state, where a `catch_all` implementation was used. For the latter the intent is however to use this feature sparingly. In most APIs new values are few and far between, so treating these as an `Err` via `TryFromPrimitive` is desired to provoke upstream issue reports and quick turnaround on new values. Same for `enum`s that are used to pass values into functions: it is desired to only pass known values (by this `ndk` crate) into those, anything else should similarly be reported and added upstream. In these cases a `#[non_exhaustive]` allows us to do so with a tiny non-breaking patch release.
Hardware buffers can have private formats which don't appear in the NDK header. Add a catch-all variant to avoid panicking in
HardwareBuffer::describe().