warning: unused return value of `std::boxed::Box::<T>::from_raw` that must be used
--> gstreamer-rtsp-server/src/rtsp_session_pool.rs:23:5
|
23 | Box::<F>::from_raw(ptr as *mut _);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
= note: call `drop(from_raw(ptr))` if you intend to drop the `Box`
Represents combinations of flags with a '+' separated string of nicks,
or an empty string for no flags set.
Note that most flag types will ignore any flags using multiple bits when
serializing, since in most cases these flags cover all used bits.
They don't add any safety as this is via unsafe code anyway and are not
needed to get mutable references in this context anyway, while adding a
bit of runtime overhead.
warning: this expression borrows a value the compiler would automatically borrow
--> gstreamer-rtsp-server/src/rtsp_session_pool.rs:16:5
|
16 | (&mut *func.borrow_mut())(&from_glib_borrow(pool)).into_glib()
| ^^^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `(*func.borrow_mut())`
|
= note: `#[warn(clippy::needless_borrow)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
This reverts commit 8226c94110.
Now that GStreamer 1.20 is out, the v1_20 feature can and should link
directly to the stable release instead of the unstable 1.19 development
release.
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.
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`.
The generator does not read Gir.toml from dependencies, missing out on
trait renames like `ObjectExt` turning into GstObjectExt` (to prevent
clashes with `glib`'s `ObjectExt`). Renaming through `trait_name` is
now taken into account in `gir` thanks to [1], but the renames still
need to be availble to all crates referencing this type. Fortunately
only `Gst.Object` is affected - other renamed traits are not extended in
any of the other crates.
[1]: https://github.com/gtk-rs/gir/pull/1108
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 generator is now solely in charge of the output path. Besides, only
few crates were inconsistently defining this path while the rest was
leaving it up to a default or the path specified on the cmdline.
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.
If we don't handle the case of RTSPServer::attach() failing, we end up
with a panic. Unfortunately, we don't get any details from the
underlying call so we've to live with a generic error. :(
