-
Notifications
You must be signed in to change notification settings - Fork 734
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do you use LevelFilter with <
or <=
?
#1993
Comments
After reading the docs again, the only thing that makes sense is the 2nd one. |
FWIW, I also got mighty confused with the documentation for |
This inconsistency confused me today too. It seems like the docs for #1669 pointed out that the docs said:
The docs were updated to say:
...but I think they should have been updated to say:
|
Just few notes:
|
Ok, I haven't checked |
These docs were updated (in response to tokio-rs#1669), but the "or equal to" phrase should have been moved to the other case. Fixes: tokio-rs#1993
These docs were updated (in response to #1669), but the "or equal to" phrase should have been moved to the other case. Fixes: #1993 ## Motivation When these docs were updated in response to #1669, they were updated incompletely (a level that is equal to a filter is _enabled_, not _disabled_) and therefore remained incorrect. ## Solution The docs were updated, moving the "or equal to" phrase to the other case.
These docs were updated (in response to #1669), but the "or equal to" phrase should have been moved to the other case. Fixes: #1993 ## Motivation When these docs were updated in response to #1669, they were updated incompletely (a level that is equal to a filter is _enabled_, not _disabled_) and therefore remained incorrect. ## Solution The docs were updated, moving the "or equal to" phrase to the other case.
These docs were updated (in response to #1669), but the "or equal to" phrase should have been moved to the other case. Fixes: #1993 ## Motivation When these docs were updated in response to #1669, they were updated incompletely (a level that is equal to a filter is _enabled_, not _disabled_) and therefore remained incorrect. ## Solution The docs were updated, moving the "or equal to" phrase to the other case.
…-rs#2767) These docs were updated (in response to tokio-rs#1669), but the "or equal to" phrase should have been moved to the other case. Fixes: tokio-rs#1993 ## Motivation When these docs were updated in response to tokio-rs#1669, they were updated incompletely (a level that is equal to a filter is _enabled_, not _disabled_) and therefore remained incorrect. ## Solution The docs were updated, moving the "or equal to" phrase to the other case.
…-rs#2767) These docs were updated (in response to tokio-rs#1669), but the "or equal to" phrase should have been moved to the other case. Fixes: tokio-rs#1993 ## Motivation When these docs were updated in response to tokio-rs#1669, they were updated incompletely (a level that is equal to a filter is _enabled_, not _disabled_) and therefore remained incorrect. ## Solution The docs were updated, moving the "or equal to" phrase to the other case.
Bug Report
Version
Platform
Microsoft Windows Version 21H2 (OS Build 19044.1586)
Crates
tracing-core
Description
When checking if a level is (statically) enabled, is it
Level::TRACE < STATIC_MAX_LEVEL
orLevel::TRACE <= STATIC_MAX_LEVEL
?LevelFilter
docs:LevelFilter::current
docs:The type docs seem to say that
is_enabled = level < filter
andis_disabled = level >= filter
.The method docs seem to say that
is_disabled = level > filter
andis_enabled = level <= filter
.Which one is it?
The text was updated successfully, but these errors were encountered: