This struct is "reimplemented" to make it easier to access the fields
instead of going through `ffi::GstVideoRectangle`, but should be marked
`repr(C)` to remain binary-compatible.
The `links` annotation in `Cargo.toml` is intended to ensure that in the
crate graph there's at most one crate that's an implementation of
some sort concept.
This can make sense in some scenarios, most prominent of which is when
the crate defines `#[no_mangle]` symbols (e.g. by compiling a vendored C
library.) In that situation linking a binary that depends on two
versions of the library cannot work because of colliding symbol names.
There does not appear to be a similar reason to impose such a
restriction on the users of `gstreamer-sys` and similar, however. All of
these crates link to a system library, they do not define any
`#[no_mangle]` symbols nor they vendor and build C libraries as part of
their build process. All they do is linking to a system library. Most
likely all the different versions of the bindings will link to the exact
same library too.
I haven't seen any global resources that these bindings use to ensure
soundness of the library, either.
Now that the crates are generated and linked against v1_20 binaries
there is no need to guard this codepath when building `dox` (which
inherently enables `v1_20` but did previously not actually compile
against that version yet).
Gir now uses analyzed objects to generate documentation, and to know
exactly what is available. Additionally, this allows more bindings to
be generated.
This version adds a `--strip-docs` flag to `generator.py`, used in
conjunction with `--strip-docs --embed-docs` to clean documentation
first before re-embedding it (otherwise the same text would show up
multiple times). It is also used in the CI to check that no
documentation disappears on stripping, ie. all documentation is properly
annotated with `// rustdoc-stripper-ignore-next`.
Also separate the lower/upper bound in the name with an underscore. This
cannot be added between `Range` and the first number, that's violating
`non_camel_case_types`.
When importing the prelude of a crate like `gst` the `glib` prelude is
provided too. Shedding these imports saves quite a few lines and
adheres to keeping it simple; we're not reexporting base/parent preludes
for no reason :)
For cleanliness the prelude module only needs to reexport preludes from
direct, "top-most" crates, which themselves take care of reexporting
preludes from its dependencies again. This shaves off some code while
maintaining the same set of exports.
In gir it was brought up [1] that some traits (in particular
`*ExtManual`) are exported from the crate root in addition to the
prelude, cluttering the environment unnecessarily. This commit removes
all these reexports, leaving those in prelude (that were already there)
only.
After this commit everything matching `Ext(Manual)?\b` in `lib.rs` sits
within `pub mod prelude {};`.
[1]: https://github.com/gtk-rs/gir/pull/1111
The `lgpl-docs` and documentation embedding step is now solely invoked
from `./gir/generator.py` in the CI, and does not need the embed/purge
build features anymore.
The `lgpl-docs` crate and all precompiled (easy to get outdated!)
docmentation files are removed in favour of being generated at runtime
by the improved generator, both during local development as well as in
the CI.
The previous commit reinstantiated `girs_dir`, and this commit applies
the rename to `girs_directories` and adds the new/missing
`gst-gir-files` directory where GStreamer-specific `.gir` files live.
This reverts commit 7f9fcb09e2.
`generator.py` is in the process of being moved to a generic place in
the `gir` repository for reuse across crates. This means `-d` cannot be
passed for our GStreamer-specific `gst-gir-files` directory anymore, and
should be configured from `Gir.toml` instead.
Gir now prints all directories and their hashes in the version file and
comments; useful now that gstreamer-rs is being generated from both
gir-files/ and gst-gir-files/ submodules.
We were already using `gir -d` and especially now that our files are
separated across two directories that are relative to the directory
containing Gir.toml this only becomes cumbersome. Besides `gir` lacks
functionality to normalize the path, leading to ie.
gstreamer-gl/egl/sys/../../../gir-files in the version comment as a
result.
The sys crates have not been generated with 1.20 introspected gir files
yet, and break the documentation that is already compiling with the
v1_20 feature. Function body contents don't truly matter for the
documentation build anyway.
This scales better as there will only be only such data instead of two
or more when having deeper class hierarchies with multiple Rust
elements, and also makes it unnecessary to use a special instance struct
so the default works well.
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.
