Lossy parse log filter if it comes from env variable
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 161
Description
## What problem does this solve or what need does it fill?
When setting a log filter through an environment variable `RUST_LOG`, use lossy parsing to go on with the directives that do work. This will make it consistent with the lossy parsing that happens when the filter comes from `LogPlugin.filter`.
## What solution would you like?
We can reuse tracing-subscriber their `env_var_name` method (see tracing-subscriber-0.3.18/src/filter/env/builder.rs) after they expose it as public to reuse their code. An issue has been made on their repo for this: https://github.com/tokio-rs/tracing/issues/3009.
After this is done, we can lossy parse the env variable if its set (which will output a log if there's a faulty directive). If the environment variable is not set, default to the `LogPlugin.filter` as it currently does.
In the solution, running an app with `RUST_LOG="my_package=invalid_log_level,naga=warn" cargo run` should result in an error being printed for the `my_package=invalid_log_level` directive while the valid `naga=warn` will be used.
## What alternative(s) have you considered?
We can work around it by using tracing-subscriber its `EnvFilter::DEFAULT_ENV` but ideally we'd reuse their code. This is better so that one we want to have the option to overwrite the environment variable that is used, we could leverage their builder instead of providing our own logic.
## Additional context
This is a follow-up (and dependent on) #13897.
Contributor guide
Assessment
This issue has not been assessed yet.