This should be analogous to C struct initalizers where all unspecified
fields are initialized to zero. Without mut this reads a bit nicer as
well.
Note that two out of three structs have all members specified, hence
need no zero-initialization of the remainder at all.
As ffi::GstVideoTimeCode implements Copy, assignments don't move it out
of the passed in value but just copy it. This doesn't increase the
reference count of the daily jam, still runs the Drop impl of the passed
in value to decrease the daily jam and then causes a second unref of it
later when the returned value is dropped.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/310
gir has been fixed to omit all unnecessary imports from objects, enums
and flags which currently are the only offenders of this linter warning.
Hence disallow this warning from now on which is anyway not applied to
every crate - like gstreamer-gl - where such issues have been uncovered.
Clippy nightly is becoming surprisingly smart these days:
warning: This sequence of operators looks suspiciously like a bug.
--> gstreamer-video/src/video_time_code_interval.rs:66:16
|
66 | && self.0.minutes == other.0.hours
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: I think you meant: `self.0.minutes == other.0.minutes`
|
= note: `#[warn(clippy::suspicious_operation_groupings)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#suspicious_operation_groupings
This function was named wrong before 1.20, and its return transfer type
changed from none to full. To provide
Note that, when 1.20 Gir files are imported, this `version` override in
gstreamer-video/Gir.toml wil come into effect and create a Display trait
for us (without version constraint). At that point the manual Display
impl should be removed, but the manual to_string implementation remains.
{Audio,Video}Endianness is an enumeration to represent the two possible
values in Rust but this enumeration does not exist as such in C, where
it is merely an integer with some constants defining possible values.
Capitalization is wrong in function and parameter/variable names:
warning: method `get_Kr_Kb` should have a snake case name
--> gstreamer-video/src/auto/enums.rs:515:12
|
515 | pub fn get_Kr_Kb(&self) -> Option<(f64, f64)> {
| ^^^^^^^^^ help: convert the identifier to snake case (notice the capitalization): `get_kr_kb`
|
= note: `#[warn(non_snake_case)]` on by default
warning: variable `Kr` should have a snake case name
--> gstreamer-video/src/auto/enums.rs:518:21
|
518 | let mut Kr = mem::MaybeUninit::uninit();
| ^^ help: convert the identifier to snake case (notice the capitalization): `kr`
warning: variable `Kb` should have a snake case name
--> gstreamer-video/src/auto/enums.rs:519:21
|
519 | let mut Kb = mem::MaybeUninit::uninit();
| ^^ help: convert the identifier to snake case (notice the capitalization): `kb`
warning: variable `Kr` should have a snake case name
--> gstreamer-video/src/auto/enums.rs:525:17
|
525 | let Kr = Kr.assume_init();
| ^^ help: convert the identifier to snake case (notice the capitalization): `kr`
warning: variable `Kb` should have a snake case name
--> gstreamer-video/src/auto/enums.rs:526:17
|
526 | let Kb = Kb.assume_init();
| ^^ help: convert the identifier to snake case (notice the capitalization): `kb`
These functions have been checked to never return NULL. The overrides
can hopefully be gone again when C contains better annotations and
trust_return_value_nullability is enabled.
