Logging facade

[ratijas]

Not sure is it just me, or the logging functionality does not work from Qt side by default. I had to copy the handler function from qmetaobject tests, and explicitly install with install_message_handler function.

Now, given that there is a message type enum QtMsgType {QtDebugMsg, QtWarningMsg, ...} it should be easy to add a function which forwards Qt's messages to the rust logging facade's info!, warn!, ....

[ratijas]

Since this is going to be a pass-through system, it is crucial to retain as much context as possible.

log! has a notion of "target" — tag / name / context / module / whatever prefix to figure out where this line is coming from.

Fortunately, there is a notion of a "category" in Qt's logging system, implemented as const char * string, and wrapped together with severity (level) in a QLoggingCategory class.

When exposed through qInstallMessageHandler's QtMessageHandler callback signature, category can be retrieved via QMessageLogContext::category member field. And there are already wrappers for that in qmetaobject! They even take care on null values. The only thing is, according to Qt source code, default value for a category is (surprisingly) a "default" string, not an empty one.

[ratijas]

We've had a big discussion on Telegram Rust group regarding lifetimes, arguments formatting and problems related to format_args! macro, and came to the conclusion that match with single all-capturing arm is a common trick to allow retention of temporal objects for "a little bit longer". So, my final version looks like this:

use log::{Level, logger, Record};
use qmetaobject::*;
use qmetaobject::QtMsgType::*;

fn map_level(lvl: &QtMsgType) -> Level {
    match lvl {
        QtDebugMsg => Level::Debug,
        QtWarningMsg => Level::Warn,
        QtCriticalMsg => Level::Error,
        QtFatalMsg => Level::Error,
        QtInfoMsg => Level::Info,
    }
}

extern "C" fn log_capture(msg_type: QtMsgType,
                          context: &QMessageLogContext,
                          message: &QString) {
    let level = map_level(&msg_type);
    let target = match context.category() {
        "" => "default",
        x => x,
    };
    let file = match context.file() {
        "" => None,
        x => Some(x),
    };
    let line = match context.line() {
        // line numbers start from 1, right?
        0 => None,
        x => Some(x as _),
    };
    let mut record = Record::builder();
    record.level(level)
        .target(target)
        .file(file)
        .line(line)
        .module_path(None);
    match context.function() {
        "" => match format_args!("{}", message) {
            args => logger().log(&record.args(args).build()),
        },
        f => match format_args!("[in {}] {}", f, message) {
            args => logger().log(&record.args(args).build()),
        }
    }
}

Note that most context data is retained as first-class members of rust logging facade, except for context->function which is included in formatted arguments as-is.

[ogoffart]

Sounds like a good idea that could be put behind a feature

[ratijas]

behind a feature

Exactly what I thought as well! The only other option is a separate micro-crate, but that's just too much of a left-pad, and also heavily depends on core qmetaobject-rs anyway.

[ratijas]

On the second thought, log facade is very lightweight, is feature-gate really needed?

Logger cannot register itself upon startup, user has to call initialization routine manually anyway. So having feature to prevent auto-registration is not the case, because there is no auto-registration possible in rust.

[ratijas]

Implemented in #86