Transform liblog into a logging facade

[rust-lang]

Transform liblog into a logging facade

[alexcrichton]

This seems like a pretty great idea! I don't personally have many strong opinions about logging or what direction this library should go in, and I also don't mind deprecating this library as-is (just going into maintenance mode) to make room for another.

Some thoughts:

The log levels are now an enum instead of a u32

This seems like a good idea.

The logging macros don't call enabled before calling log

Some use cases of logging may hurt because of this, but I'd be willing to believe that they're fairly few and somewhat niche.

There is now a single global logger instead of thread-local loggers

This also seems like a good idea.

In addition, it's not totally clear to me that anyone actually wants to have different loggers on different threads

The one use case I know of for this is a unit testing framework where you want to capture each test's output individually. As you mentioned though you can build this on top of a global framework so it's probably not that bad to lose.

The logger may only be initialized once, and isn't torn down when a program exits

The lack of teardown seems somewhat worrying to me, but the one-time initialization is probably fine.

The strategy I'm going to try to take elsewhere is that once atexit starts running, it's considered a task panic to continue accessing logging. This means that you'll need synchronization around it, but it probably all comes out in the wash.

A logger has to be manually installed

This seems somewhat reasonable. If I've invested time and effort into using a logging infrastructure I'm probably willing to set it up to get it running.

[sfackler]

The lack of teardown seems somewhat worrying to me, but the one-time initialization is probably fine.

The strategy I'm going to try to take elsewhere is that once atexit starts running, it's considered a task panic to continue accessing logging. This means that you'll need synchronization around it, but it probably all comes out in the wash.

Yeah, thinking about it a bit more, you'd definitely want teardown to flush buffers at the very least. I'm not a huge fan of having post-atexit calls panic. Seems like they should just be noops to avoid weird transient failures that are hard to reproduce.

[sfackler]

Adding at_exit cleanup wasn't that bad, though the implementation involves some "interesting" uses of atomics: https://github.com/sfackler/log-ng/commit/0bc99ed5b0e2b0f417257921cda78c5ef3612f7b.

I also don't mind deprecating this library as-is (just going into maintenance mode) to make room for another.

I'd prefer to keep the implementation in the log crate since it'd be a bummer to burn a good name so quickly. That could mean keeping it in this repo or just transferring ownership on crates.io.

[alexcrichton]

That's a good point, I wouldn't mind moving this crate more towards a different design, may want to discuss with a few others though :)

[Ericson2314]

The logging macros don't call enabled before calling log

I would like it if in addition to the dynamic logging level, there was a static logging level -- a compile time choice of what types of logging are even available. This should recover all the niche uses of the old system and impose no burdens the common case.

If cfg! wasn't used in the logging macros (for the static level) but #[cfg(.,.)] instead, the logging facade could be unconditionally #[phase(plugin)] externd, and conditionally be #[phase(link)] externd to completely go away at the most restrictive static logging level.

[sfackler]

A static logging level seems like a great idea. I've been worrying a bit about debug! and trace! being tied to ndebug, but a separate cfg seems like a better way of handling that.

#[cfg(...)] can't be attached to expressions right now, which would prohibit its use here. cfg! should be fine, as if cfg!(foo) { stuff } ends up as if false { stuff } which is trivially optimized away. In fact, I believe the removal of if false {..} blocks is one of the very few optimizations performed by rustc itself instead of llvm.

[sfackler]

@Ericson2314 is this something like what you had in mind? https://github.com/sfackler/log-ng/commit/f40621c311ab82af8ded28b79566ccdcec427d99

[Ericson2314]

Glad you like it!

That's most of it. My thing about cfg! vs #[cfg(.,.)] is that in the case where logging is effectively statically disabled, log probably won't get linked in the end, but could anyways. By aggressively using #[cfg(...)] it might be possible to guarantee log goes away entirely -- and that might be a useful invariant for people distributing proprietary binaries or something.

What do we use ndebug for currently? If just for debug_assert and friends, might we remove it altogether now that log is becoming is so much more flexible?

[sfackler]

I believe debug_assert is the only thing built into the standard distribution that uses ndebug.

We could potentially do something like this, though it's pretty bizzaro looking:

macro_rules! debug {
    ($($arg:tt)*) => (
        match () {
            #[cfg(not(any(log_level = "off",
                          log_level = "error",
                          log_level = "warn",
                          log_level = "info")))]
            () => log!(::log_ng::LogLevel::Debug, $($arg)*),
            #[cfg(any(log_level = "off",
                      log_level = "error",
                      log_level = "warn",
                      log_level = "info")))]
            () => (),
        }
    )
}

[Ericson2314]

That's a great trick!

I'm now firmly in scrapping debug_assert. If debug_assert is /used/ by the standard library, not merely defined in it. liblog can be used, and just compiled out for release.

[sfackler]

Keep in mind that debug_assert! has nothing to do with logging. It's just like assert! except that it turns into a noop when compiled with ndebug.

[Ericson2314]

Well debugging and logging are related, broadly. And having one library to manage all optional sanity checks seems convenient.

[Ericson2314]

Hmm, I'm trying

#[macro_use] #[no_link]
extern crate log_ng;

#[cfg(any(log_level = "off",
          log_level = "error",
          log_level = "warn",
          log_level = "info",
          log_level = "debug"))]
extern crate log_ng;

But it doesn't seem to be working. Perhaps those cfgs are being resolved in log_ng itself?

[sfackler]

Are you passing one of those to rustc?

[Ericson2314]

no, but the macros are asking for things in log_ng.

[sfackler]

The macros expand inline into crates that use them, and that's where the cfg takes effect.

[Ericson2314]

Oh no. Is there anyway to delay that?