This fixes the following error when using Rust 2018 style macro imports.
use log::info;
fn main() {
info!("...");
}
error: cannot find macro `log!` in this scope
--> src/main.rs:4:5
|
4 | info!("...");
| ^^^^^^^^^^^^^
The `local_inner_macros` modifier resolves all macro invocations made
from within that macro as macros in the same crate. So if `info!`
expands to an invocation of `log!` then this would be resolved as
`$crate::log!` rather than requiring the caller to have `log` in scope.
The attribute is ignored by pre-2018 compilers so log will continue to
work as normal with #[macro_use].
In the future when dropping compatibility with pre-2018 compilers we can
remove the `local_inner_macros` modifier and use our own explicit
`$crate::` prefixes on invocations of local macros.
If `set_logger_inner` is called while `STATE` is `INITIALIZING`, make it
wait until the `STATE` is `INITIALIZED` so that callers can assume that
the logging state is fully initialized after a call to
`set_logger_inner`.
The extra work involved in loading the logger and creating the record
struct involves move codegen than is necessary if we take this kind of
approach (which we previously used in 0.3). It's a bit unfortunate to
have these public-but-not-public functions, but I think it's worth it.
We want to minimize the footprint of logging so people feel comfortable
using it!
A main function containing nothing but `warn!("hello world")` shrinks
from 204 bytes to 124 bytes in x86_64 with this change.
Closes#275
This is required by some deserializers which deserialize identifiers using their binary representation.
This implementation should be equivalent to what serde derive would implement.
try_set_logger_raw is now set_logger and try_set_logger is now
set_boxed_logger. The use_std feature is now disabled by default. The
old set_logger has been removed.
When we did the crate evaluation for log, we wanted to add more variants
of set_logger that e.g. panicked by default, but I'm no longer convinced
that's a good idea. There are going to be very few instances of actually
calling these methods explicitly, since each logger implementation
should be providing their own init method that calls them. Having a huge
constellation of functions that all do basically the same thing just
makes things really confusing. We also don't want to encourage logger
implementations to only provide an init function that panics because a
common way of working with logging in tests is to try to init the system
in each test and ignore the result.
This allows us to make try_set_logger_raw a safe function. It turns out
that every example dealing with that function was violating the static
lifetime requirement. Fun!
They now take a `&Record` and `&Metadata` respectively. Shim libraries
from other logging frameworks will want to construct these types
directly rather than using the log macros.
