Commits on Source (19)
-
This macro tries to do the same things as the one in C but in a Rust-ty way. Signed-off-by:
Alexandre Janniaux <ajanni@videolabs.io> Picked from main rust MR as-is, so it won't be compiling correctly. Follow-up changes will add the crates to the workspace members after adapting to the new tree. The crate will provide the module!{} macro to define the plugin manifest in a declarative and type-safe way, bringing the language part to create new modules in Rust. Only the buildsystem part will be missing after this crate is enabled.
a1036731 -
053f4c38
-
cargo clippy was complaining that the loop would trigger only once. Indeed, the for-loop is used to trigger iter() and return immediately with an error at the first element. Using if-let deconstructuring construct on the first() element achieve the same feature while providing more semantics on what it is checking.
a054d5d8 -
The format!() call has no formatting argument, so returning an str slice is enough.
863f1891 -
d38c1070
-
9a2d8a88
-
The vlcrs-plugin crate exports structures matching vlc_plugin.h, which is ough to be included by modules directly or indirectly (through vlcrs-macros) to define every parts needed to setup the module manifest. The current state exports a minimal set required for the current vlcrs-macro code to work correctly.
6f7b912f -
7a626bfc
-
vlcrs_core doesn't exist anymore since we've splitted the crates for each matching header in vlccore, and some of the defines have been renamed since we can provide a better name through context as opposed to C code. Some of the types don't exist, namely vlcrs-plugin::ModuleArgs, because they depends on vlc_variable. This commit still changes those locations so that we can remove the correct version while keeping the revert possible on future commits.
3afe5bec -
Those will be used from the tests to display nicer names when parsing the module manifest.
213ba900 -
`param` was already a reference so there's no need to re-enforce a reference here.
54981398 -
This will require vlc_variable support, which is not merged yet. The patch will be reverted as soon as vlc_variable can be used.
75c0955c -
The trait defines a protocol to be implemented by any "Loader" for the "CapabilityTrait". Both terms will be defined in follow-up commits. In particular, this trait enforce the module loaders to provide the activation function and deactivation function, as well as providing default values for the deactivation functions. More in-depth experiments were done to extend this approach to the capability trait, so that traits defining a capability and traits defining the ModuleLoader interface are separated, but automatically implementing a capability trait for module structures that would use the capability interface requires the following kind of declaration: impl<T : SpecificCapabilityTrait> CapabilityProtocol for T where T : SpecificCapabilityTrait { type Activate = vlc_activate; type Deactivate = vlc_deactivate; type Loader = ModuleLoader<Self>; } In this case, the implementation of the trait is done in crates exposing the capability, for instance vlcrs-interface or an external crate exposing an out-of-tree module, and the CapabilityProtocol is exposed by the vlcrs-plugin crate, so it is considered as a generic implementation of a foreign type, which is not allowed and would end up with the following error: error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`) --> vlcrs-macros/tests/module.rs:52:6 | 52 | impl<T : SpecificCapabilityModule> CapabilityProtocol for T | ^ type parameter `T` must be used as the type parameter for some local type | = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local = note: only traits defined in the current crate can be implemented for a type parameter Some errors have detailed explanations: E0210, E0576. For more information about an error, try `rustc --explain E0210`.
183d214e -
The capability trait will embed the type system which brings the activation and deactivation function for the module, as well as some future changes regarding capability checking at compile time. Forcing to specify the capability trait enables a struct to be implemented by multiple capabilities, and enable the module manifest macro to know which capability trait is actually associated with which capability specification, and will enable static checks to be performed at compile time.
fc186db0 -
The previous implementation from Loïc Branstett was using public activation and deactivation functions that would be fetched from the capability name. But it meant that capabilities could not have spaces in them, removing the possibility to use "video filter" or requiring to patch the name beforehand, and it was fit to a model with a single crate so as to know where to find the activation functions. Since the introduction of the binding generator in commit bd1aaaf4, our crates are separated and sorted to match each include file from vlccore. In addition, it meant that it would not have been possible to write out-of-tree capabilities while enjoying the type-safe features brought by the bindings, as opposed to the current C API. Finally, it was also not compatible with custom loading function type. This commit brings a new indirection by allowing capability traits to define `Loader`, `Activate` and `Deactivate` types in their definitions, in an effort to keep a type-safe interface when __writing__ modules, as well as being able to easily describe new module interfaces without compromising on the current features of the module infrastructure. Module Implementor Core support - Implement capability - Provides capability traits traits - Provides module loader functions The types `Activate` and `Deactivate` would allow to define custom activation function type, such as those we find when using vlc_module_load or manually probing using vlc_module_match, as opposed to the common vlc_object_t-based module_need() activation function. The type `Loader` allows to define a default associated type that would provide the activation functions to the module manifest writer, so that the correct interface is used. It effectively allows capability traits to define custom activation function types, without having the module implementor explicitely provide those functions. The module implementor is still able to provide their own activation functions by providing their own loader.
190ba5a5 -
The module!{} macro documentation should now expose an existing dedicated capability trait and specify the loader. We don't want that to be visible from the module!{} macro, so everything is hidden, but we might want to replace the specific capability by an exisiting capability trait when some will exist in the future, so that the documentation is simplified and the example matches real life usage. Otherwise, the doctest could be turned into `ignore` instead of `no_build` but it means that the documentation could become out-of-date with what the users are supposed to do.
c76dff98 -
After this commit, vlcrs-macros must pass the tests and doctests.
2da6855c -
The tests are checking: - [x] whether the module manifest has wanted opcode generated - [ ] whether the module manifest is 100% correct - [ ] whether the arguments for the module manifest opcode are correct - [x] whether we can create modules with usual activation functions - [x] whether we can create modules with custom activation functions - [x] whether we can omit the deactivation function - [x] whether the activation function is correctly called - [x] whether the deactivation function is correctly called - [x] whether the infrastructure works for submodules The test module.rs provides a simple test with normal interface to check the module manifest with open and close functions. The test module_multiple.rs is important to ensure the macro doesn't generate code with duplicated identifiers, that would trigger errors only when multiple modules are declared from a single manifest. The test module_default.rs checks the minimal definition required for core module loading implementation to define a new capability, using the default functions as much as possible. The test module_specific checks that we can use other signatures and uses this feature to check that the activation and deactivation functions are correctly called when using the module API.
15d9c3b7 -
0b3d497a
Showing
- modules/Cargo.toml 2 additions, 0 deletionsmodules/Cargo.toml
- src/rust/Cargo.toml 2 additions, 0 deletionssrc/rust/Cargo.toml
- src/rust/Makefile.am 5 additions, 0 deletionssrc/rust/Makefile.am
- src/rust/vlcrs-macros/Cargo.toml 14 additions, 0 deletionssrc/rust/vlcrs-macros/Cargo.toml
- src/rust/vlcrs-macros/src/lib.rs 143 additions, 0 deletionssrc/rust/vlcrs-macros/src/lib.rs
- src/rust/vlcrs-macros/src/module.rs 1119 additions, 0 deletionssrc/rust/vlcrs-macros/src/module.rs
- src/rust/vlcrs-macros/tests/module.rs 104 additions, 0 deletionssrc/rust/vlcrs-macros/tests/module.rs
- src/rust/vlcrs-macros/tests/module_default.rs 102 additions, 0 deletionssrc/rust/vlcrs-macros/tests/module_default.rs
- src/rust/vlcrs-macros/tests/module_multiple.rs 160 additions, 0 deletionssrc/rust/vlcrs-macros/tests/module_multiple.rs
- src/rust/vlcrs-macros/tests/module_specific.rs 150 additions, 0 deletionssrc/rust/vlcrs-macros/tests/module_specific.rs
- src/rust/vlcrs-plugin/Cargo.toml 7 additions, 0 deletionssrc/rust/vlcrs-plugin/Cargo.toml
- src/rust/vlcrs-plugin/src/lib.rs 255 additions, 0 deletionssrc/rust/vlcrs-plugin/src/lib.rs
- src/rust/vlcrs-plugin/src/sys.rs 4 additions, 0 deletionssrc/rust/vlcrs-plugin/src/sys.rs
src/rust/vlcrs-macros/Cargo.toml
0 → 100644
src/rust/vlcrs-macros/src/lib.rs
0 → 100644
src/rust/vlcrs-macros/src/module.rs
0 → 100644
src/rust/vlcrs-macros/tests/module.rs
0 → 100644
src/rust/vlcrs-plugin/Cargo.toml
0 → 100644
src/rust/vlcrs-plugin/src/lib.rs
0 → 100644
src/rust/vlcrs-plugin/src/sys.rs
0 → 100644