subscriber: fix issue with EnvFilter::builder().parse

[Ma124]

Motivation

See issue #2046.
When using calling Builder::parse or Builder::parse_lossy with an empty
string an error is produced. This happens for example when EnvFilter::from_default_env()
is called, but the RUST_LOG variable is unset.
This regression was introduced by #2035.

Solution

Filter any empty directives. This allows the whole string to be empty, as well as leading
and trailing commas.
A unit test was added for Builder::parse, but not Builder::parse_lossy because it (per definition)
doesn't produce any side effects visible from tests when erroring.

[Ma124]

I'm pretty sure this works correctly, but I had trouble testing it with my own applications because of reasons unrelated to these changes.

Maybe, you as maintainers, encountered this when testing your changes:

tracing-subscriber = { version = "0.3.10", features = ["env-filter"] }
tracing-subscriber = { git = "https://github.com/tokio-rs/tracing.git", tag = "tracing-subscriber-0.3.10", features = ["env-filter"] }

When I have the first line in my Cargo.toml and use error!, the message is correctly printed.
When I have the second line (instead of the first), which should pull exactly the same version, in my Cargo.toml, suddenly no messages are printed. This happens with RUST_LOG=trace as well.

[hawkw]

Thanks, this looks good to me!

[hawkw]

I'm pretty sure this works correctly, but I had trouble testing it with my own applications because of reasons unrelated to these changes.

Maybe, you as maintainers, encountered this when testing your changes:

tracing-subscriber = { version = "0.3.10", features = ["env-filter"] }
tracing-subscriber = { git = "https://github.com/tokio-rs/tracing.git", tag = "tracing-subscriber-0.3.10", features = ["env-filter"] }

When I have the first line in my Cargo.toml and use error!, the message is correctly printed. When I have the second line (instead of the first), which should pull exactly the same version, in my Cargo.toml, suddenly no messages are printed. This happens with RUST_LOG=trace as well.

Because the master branch contains in-development changes for the upcoming tracing 0.2 release, it isn't compatible with the currently released versions. To test changes from the master branch locally, it will be necessary to patch all tracing crates to use the Git versions, not just the one that changed. Hopefully that's helpful in the future!