feat(env_filter): support no_std#404
Conversation
cagatay-y
changed the title
|
FYI I expect PRs to be presented for how they should be reviewed and merged and not for how they were developed. Please clean up the commit history |
cagatay-y
force-pushed
the
feature/filter-no_std
branch
from
b754c66 to
364726a
Compare
|
@epage, could you take another look at the PR? |
| #[cfg(not(feature = "std"))] | ||
| log::warn!("{error}, ignoring it"); |
There was a problem hiding this comment.
This is for creating the logger in the first place, so I don't think it is too meaningful to log at this point.
There was a problem hiding this comment.
At least in my use case, the filter member of the logger is a OnceCell<env_filter::Filter> and until the filter is fully initialised, the logger is returned a Option<&Filter>::None when trying to get it. When it receives the None, it simply lets the log message through, so the user is able to see the warning.
There was a problem hiding this comment.
At least in my use case,
While true, I need to consider the general case. Unless there is a reason you feel we should define this to be the general case.
There was a problem hiding this comment.
My thinking was that it is possible for it to be useful and in the worst case where no logger was set, the log will be ignored, which ends up giving the same result as not logging in the first place. However, I am also completely fine with removing the lines if you think that would be the better approach; or implementing another approach for outputting the error, if you have one in mind.
cagatay-y
force-pushed
the
feature/filter-no_std
branch
from
364726a to
2a7ae94
Compare
cagatay-y
force-pushed
the
feature/filter-no_std
branch
from
2a7ae94 to
8e062c3
Compare
|
In the latest force-push, in addition to what was raised in the review, I fixed an error I made related to the handling of the features of the |
Co-authored-by: WolverinDEV <git@did.science>
Co-authored-by: WolverinDEV <git@did.science>
cagatay-y
force-pushed
the
feature/filter-no_std
branch
from
8e062c3 to
f461d05
Compare
2 participants
Based on #378, this PR adds a new default feature
stdthat allows the crate to be used in no_std crates. I tried to incorporate the feedback that was given to the previous PR. Hopefully, I didn't miss anything.The PR is still a breaking change for crates that have the default features disabled and use
Builder::from_env, or expectBuilder::parseto print warnings to stderr and don't have the log target set to stderr.It may make sense to squash 9c70eaf and 663c9c2 (and potentially b754c66). I kept them separate to make sure I don't misattribute the work of the author of the base PR.