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
| #[macro_export] | ||
| 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. |
3 participants
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.