Fail on RUST_LOG parse error

[zthompson47]

At the top of crates/fj-app/src/main.rs there's this comment:

// It would be better to fail, if `RUST_LOG` is erroneous, but I don't know
// how to distinguish between that and the "not defined" case.

I figured out how to detect if RUST_LOG is not defined and came up with a PR that I'll attach to this issue.

My solution terminates the program with an error message if there is any type of parse error. That includes not just parsing errors in tracing_subscriber, but also the NotUnicode variant of std::env::VarError. It succeeds only if the parsing is correct or if RUST_LOG is not defined (the latter case defaults to WARN). Hopefully that's what you had in mind, but I can always revise.

I didn't write a test for this change, but I'd be happy to work on that if you think it's warranted. I feel like it's something to just manually check and assume it will continue working. That said, I've only checked the obvious cases, and e.g. haven't tested a non-unicode RUST_LOG. I guess I'm just relying on the compiler guarantees. Please advise if my thinking is off..

[hannobraun]

Again, thank you, @zthompson47!

Hopefully that's what you had in mind, but I can always revise.

Yes, that's exactly it 👍

I didn't write a test for this change, but I'd be happy to work on that if you think it's warranted. I feel like it's something to just manually check and assume it will continue working. That said, I've only checked the obvious cases, and e.g. haven't tested a non-unicode RUST_LOG. I guess I'm just relying on the compiler guarantees. Please advise if my thinking is off..

I think that tracks. If you had presented me with a test, I'd have happily merged that, but I don't think it would be worth the effort to write that test, probably.

Maybe that will change over time, as Fornjot gets more mature. But that would also mean we'd have to put infrastructure in place to make that kind of testing straight-forward.