Drop log-limiting features #3431
Conversation
|
@TheBlueMatt Let me know if this is reasonable. I think if we want to re-enable compile-time limiting we could do so by defining a limit as an associated type on |
lightning/src/util/macro_logger.rs
Outdated
| @@ -185,23 +185,12 @@ macro_rules! log_internal { | |||
| macro_rules! log_given_level { | |||
| ($logger: expr, $lvl:expr, $($arg:tt)+) => ( | |||
| match $lvl { | |||
There was a problem hiding this comment.
We can drop the match now, right?
There was a problem hiding this comment.
Ah, indeed. It seems we can actually drop the entire log_given_level macro now.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3431 +/- ##
==========================================
+ Coverage 89.22% 90.48% +1.26%
==========================================
Files 130 130
Lines 106965 111765 +4800
Branches 106965 111765 +4800
==========================================
+ Hits 95438 101131 +5693
+ Misses 8734 8252 -482
+ Partials 2793 2382 -411 ☔ View full report in Codecov by Sentry. |
|
LGTM, feel free to squash. |
Previously, LDK offered two ways to limit log outputs: filtering during runtime client-side by matching on any given `Record`'s `Level` value, as well as at compile time through the `max_level_*` feature flags. It turns out the latter approach was always broken when used outside of the `lightning` crate. Here, we therefore simply drop the feature-based filtering.
tnull
force-pushed
the
2024-11-drop-logging-features
branch
from
3afc3de to
f6af8e3
Compare
Squashed fixups without further changes. |
Fixes #3424.
Previously, LDK offered two ways to limit log outputs: filtering during runtime client-side by matching on any given
Record'sLevelvalue, as well as at compile time through themax_level_*feature flags.It turns out the latter approach was always broken when used outside of the
lightningcrate. Here, we therefore simply drop the feature-based filtering.