I am try to make miri set RUST_LOG based on MIRI_LOG, so I don't have to always set both. However, I do not even understand how we can have two logging "things" in the same project, isn't that stuff supposed to be global? @Oli any idea what is going on here?
jop
rustc uses a different log
crate
thus, different global statics
Also miri contains some funny code to change the logging format, but rustc doesn't, so messages look very different depending on where they come from
thus completely separate logging
rustc uses a different
log
crate
different crate? so extern crate log;
is not the same thing for both?
I wrote the funny miri code, feel free to nuke it, it's usefulness is not existing anymore
rustc uses a different
log
cratedifferent crate? so
extern crate log;
is not the same thing for both?
yea
woah. how that?
"it's complicated" and I forget a lot of the details
but it's a mess
crates.io log
vs rustc-distributed log
sounds like it
but okay I guess this means I need a hook on the rustc side to rebuild the logger, cant do it from miri
we used to use the rustd log
, but it caused all kinds of problems
"rebuild"?
we already are calling rustc_driver::init_logger()
I am changing RUST_LOG
during execution
but the change isnt picked up
so I need to to reread the config
yea, just call rustc_driver::init_logger()
I think
or make the change before the first call to it
I want to do the change late so that it applies to as little of rustc's own stuff as possible
though with the query-based architecture, that's kind of hard
thread 'main' panicked at 'env_logger::init should not be called after logger initialized: SetLoggerError(())', libcore/result.rs:1009:5
:(
uhm
just don't call it at program start
but then we will get no logging at all for that even if we want to, right?
or make it if env::var("RUST_LOG") { rustc_driver::init_logger() }
and create a second RUST_LATE_LOG
for miri to turn it on later if RUST_LOG
wasn't already specified
(and convert the env var from RUST_LATE_LOG
to RUST_LOG
then)
Hm. For now I just do the setting a bit earlier
with all these queries, we wouldn't get a clean separation between the miri execution and the CTFE executions anyway, right?
the latter can happen arbitrarily late
so we'd have to switch every time we fire a query, or so...
hmm... I think we're late enough in the process for that not to happen
maybe a few times
once the collector
is done, there should be little that we need that hasn't already been cached
collector
? where is that done?
for now I got this: https://github.com/solson/miri/pull/502/files
part of the compiler steps. It's basically the driving force behind everything
I mean, where in src/bin/miri.rs
is that done?
as in, where would then be a good place to initialize logging? :D
oh, I'd init logging where the miri interpretation is triggered
that seems to work, great :)