Monomorphised log statements have the wrong path in the crate_map

[brson]

If you write RUST_LOG=::help ./servo you get a list that includes modules from core, std, and servo, but not any of the many other used crates. As a result I can't turn logging on for a lot of stuff. Probably we're hitting some arbitrary limit.

Edit:

When a generic function in crate http_client gets monomorphised when compiling servo, then you have to use RUST_LOG=servo to turn the logs on instead of RUST_LOG=http_client. The problem is this line in trans:

    let modpath = vec::append(                                                                                                                                                
        ~[path_mod(ccx.link_meta.name)],                                                                                                                                      
        vec::filter(bcx.fcx.path, |e|                                                                                                                                         
            alt e { path_mod(_) { true } _ { false } }                                                                                                                        
        ));                                                                                                                                                                   
    let modname = path_str(modpath);  

It prepends the current crate's name to every logging key, so logs for http_client::response_header end up as servo::response_header.

[brson]

I'm particularly expecting to see http_client in the log map

[brson]

Right now i'm thinking this is specifically a problem compiling the module map for logs in the top-level module. http_client's log statements are all in the top level, and they work when compiling with --test, but not when used as a library.

[brson]

Indeed, when I add log statements to http_client::parser they do appear in the log map

[brson]

The log statements are all inside a generic class, so they are not being compiled with the http_client crate. so what are they being called?

[brson]

Updated the OP to reflect the actual problem.

[brson]

I think this can be fixed by converting log to a macro that uses other macros to get the module path during the original syntax expansion.

[nikomatsakis]

This may also be related to the fact that inlining does not preserve span information atm. (#1972)

[nikomatsakis]

Oh, reading more of your comments, I think I was wrong.

[pcwalton]

I don't believe this is backwards incompatible, renominating.

[graydon]

just a bug, removing milestone/nomination.

[graydon]

accepted for production-ready milestone