bevyengine / bevyengine/bevy

Lossy parse log filter if it comes from env variable

Open
#13,918 0 comments 0 reactions 0 assignees View on GitHub
A-Diagnostics C-Usability D-Straightforward S-Ready-For-Implementation X-Uncontroversial
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.