cxx-qt-lib: Add bindings for QMessageLogContext and qt_message_output

[redstrate]

This allows Rust and CXX-Qt applications to send messages to the Qt logger.

[Montel]

Hi,
could you add info in CHANGELOG file please ?
Thanks

[LeonMatthesKDAB]

Good first pass, unfortunately the lifetimes need sorting out.

[LeonMatthesKDAB]

This is not the correct type!

&*const c_char is a reference to a pointer, so similar to a const c_char**.
So reading this from Rust after being assigned in C++ is undefined behavior, as C++ thinks it's a const char*.

This needs to just be a *const c_char.

To introduce the required lifetime, you can add a single PhantomData<&'a c_char> member to the struct.
I'm a bit uncertain how that interacts with #[repr(C)]. In #[repr(Rust)] the PhantomData won't change the size of the struct, but in #[repr(C)] it might add a single byte, which unfortunately wouldn't allow us to make this type trivial...
Please use static assertions to check what happens either way :)

[redstrate]

Added, it seems like PhantomData does not change the memory layout of the struct - it's still 32 bytes. However, how do I add a static_assert for this? It looks like all of the ones in the .cpp files are checking the size of the Qt type, not the Rust type?

[LeonMatthesKDAB]

&'a *const c_char is still not the correct type for the constructor argument!

I think it just needs to be &'a CStr (see: https://doc.rust-lang.org/std/ffi/struct.CStr.html ), which is the C-compatible equivalent to &str.

For the static assertions, we could use: https://crates.io/crates/static_assertions
We have tried to avoid unnecessary dependencies, but I think this crate should be small and stable enough to not bother anyone. @ahayzen-kdab agree?

[redstrate]

I think it just needs to be &'a CStr (see: https://doc.rust-lang.org/std/ffi/struct.CStr.html ), which is the C-compatible equivalent to &str.

Oops yes, I should've known better. I use CStr all the time 😅 Will wait for andrew's opinion wrt/ static_assertions.

[redstrate]

I have added a static assertion now, let me know if we should have some others

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (e84662a) to head (438b6c4).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #814   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           71        71           
  Lines        11967     11967           
=========================================
  Hits         11967     11967           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[LeonMatthesKDAB]

The lifetimes are tricky to get right here and still need sorting out.

I also unresolved my two previous comments as both still need more work unfortunately.

[LeonMatthesKDAB]

I'm pretty happy with this PR now.
Having static_assertions would be a plus. Waiting for opinion from @ahayzen-kdab there.

[LeonMatthesKDAB]

It just occured to me that we technically don't need these...
As the Rust struct has the right memory layout with named members we can just do context.category, etc. in Rust.
We technically don't even need the constructor, as we can just create the struct entirely in Rust and it should still construct a compatible struct.

However, as we only assert the size and alignment and not the ordering of the members, I'm totally fine with keeping these functions just to be sure.

[redstrate]

question while waiting: do we rename enum values to something more sensible? in this case the names are weird to avoid collisions, since in qtlogging.h these were just an enum. hence why there' prefixed with Qt and suffixed with Msg.