implement `enabled!` #1821

guswynn · 2022-01-07T17:44:03Z

Motivation

Closes: #1668

My usecase is different than the referenced "avoid doing something expensive to log": I want to guard turning on debug mode for an ffi'd library, based on some target that represents the "module" we care about.

Solution

The macro is very similar to event!, but adds a few simplistic cases, and generates ever so slightly different code (to return the correct value always. It also skips anything to do with tracing-log. I considered (and tried), to share the impl between event! and enabled!, but must confess I am not good at macros and got stuck. I think they are sufficiently different, where copied impls, is easier to read. We already manage

Also, my project is on the crates.io version, so this would need to be backported to 0.1, I can help with that with guidance.

`enabled!` is similar to `event!`, but never dispatches an event. It also allows a simplistic version of calling it, filling in a fake message in the metadata.

guswynn · 2022-01-07T18:01:22Z

failures for netlify seem unrelated?

hawkw · 2022-01-10T23:27:22Z

failures for netlify seem unrelated?

yup, just fixed that --- I believe it was related to a new RustDoc version finding some broken links it couldn't previously detect.

hawkw

Thanks for working on this!

I really don't think implementing the enabled! hint as a special kind of event is the best approach. The enabled! macro is not a type of event. Instead, it's asking whether a span or event with a particular set of Metadata would be enabled. Therefore, I think we should only construct the Metadata, and not construct an entire event that we just throw away to get its metadata, which seems inefficient. Also, it just feels kind of weird to hang the constructors used by enabled! off of the Event type --- Event shouldn't be responsible for this.

Instead, we probably want to use the metadata! or callsite! macro to just generate the metadata, and ask if it's enabled.

hawkw · 2022-01-10T23:33:11Z

tracing-core/src/event.rs

+    /// Constructs a new `Event` with the specified metadata and set of values,
+    /// and returns whether such an event would be enabled by the current collector.
+    pub fn child_of_enabled(
+        parent: impl Into<Option<Id>>,
+        metadata: &'static Metadata<'static>,
+        fields: &'a field::ValueSet<'_>,
+    ) -> bool {
+        let event = Self::new_child_of(parent, metadata, fields);
+        crate::dispatch::get_default(|current| current.enabled(event.metadata()))
+    }
+
+    /// Constructs a new `Event` with the specified metadata and set of values,
+    /// and returns whether such an event would be enabled by the current collector.
+    pub fn enabled(metadata: &'static Metadata<'static>, fields: &'a field::ValueSet<'_>) -> bool {
+        let event = Event::new(metadata, fields);
+        crate::dispatch::get_default(|current| current.enabled(event.metadata()))
+    }


I don't think that the enabled macro should create a new Event variant; that seems incorrect to me. Subscriber::enabled Instead, I think it should just create a callsite and metadata, and call Dispatch::enabled with that metadata. I guess the intention was to ask the subscriber if it would enable an event with specific field values...but filtering isn't performed on field values anyway, so there's no point in having this take field values.

Similarly, I don't believe child_of_enabled should exist, as it does nothing. enabled is only called with Metadata, and Metadata doesn't include the parent span.

should we just not support parent: in the enabled! macro?

yeah, the macro shouldn't accept a parent or field values.

hawkw · 2022-01-10T23:36:04Z

tracing-core/src/metadata.rs

@@ -382,6 +383,11 @@ impl Kind {
    /// `Span` callsite
    pub const SPAN: Kind = Kind(KindInner::Span);

+    /// `enabled!` callsite. [`Collect`][`crate::collect::Collect`]'s can assume


Suggested change

/// `enabled!` callsite. [`Collect`][`crate::collect::Collect`]'s can assume

/// `enabled!` callsite. [`Collect`][`crate::collect::Collect`]s can assume

hawkw · 2022-01-10T23:37:23Z

tracing/src/macros.rs

+                $crate::Event::child_of_enabled(
+                    $parent,
+                    meta,
+                    &$crate::valueset!(meta.fields(), $($fields)*)


I don't think this should take field values, only field names. as I discussed in my comment on the new Event constructors you added, the Collect::enabled method doesn't care about field values, as it's only called with Metadata, not a full event. We should not include field values in the macro.

hawkw · 2022-01-10T23:38:05Z

tracing/src/macros.rs

+///
+#[macro_export]
+macro_rules! enabled {
+    (target: $target:expr, parent: $parent:expr, $lvl:expr, { $($fields:tt)* } )=> (


I don't think this should take a parent span. As I discussed in my comment on the new Event constructors you added, the Collect::enabled method doesn't care about overridden span parents. The macro should not include a parent span.

oh I see here now, sounds good!

hawkw · 2022-01-10T23:39:21Z

tracing/src/macros.rs

+    (target: $target:expr, parent: $parent:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => (
+        $crate::enabled!(
+            target: $target,
+            parent: $parent,
+            $lvl,
+            { message = format_args!($($arg)+), $($fields)* }
+        )
+    );


Hints shouldn't have a message. They could have a message field name, if the intent is to test if an event with a message would be enabled. But they should never actually generate a formatted message, as nothing will ever format it. This macro arm should be removed.

hawkw · 2022-01-10T23:40:05Z

tracing/src/macros.rs

+    (target: $target:expr, parent: $parent:expr, $lvl:expr, $($arg:tt)+) => (
+        $crate::enabled!(target: $target, parent: $parent, $lvl, { $($arg)+ })
+    );


this macro arm is for formatting a message from format_args!, but we shouldn't do that. this should be removed.

hawkw · 2022-01-10T23:41:27Z

tracing/src/macros.rs

+    (target: $target:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => (
+        $crate::enabled!(
+            target: $target,
+            $lvl,
+            { message = format_args!($($arg)+), $($fields)* }
+        )
+    );
+    (target: $target:expr, $lvl:expr, $($k:ident).+ = $($fields:tt)* ) => (
+        $crate::enabled!(target: $target, $lvl, { $($k).+ = $($fields)* })
+    );
+    (target: $target:expr, $lvl:expr, $($arg:tt)+ ) => (
+        $crate::enabled!(target: $target, $lvl, { $($arg)+ })
+    );


these are for formatting a format_args! message, and for field values. i don't think we should have these.

hawkw · 2022-01-10T23:41:55Z

tracing/src/macros.rs

+    // This cases is added on top of how `event` works
+    ( $lvl:expr ) => (
+        $crate::enabled!(target: module_path!(), $lvl, { "hint_message" })
+    );


we shouldn't need this if we don't include a message value.

hawkw · 2022-01-10T23:42:39Z

tracing/src/macros.rs

+    // This cases is added on top of how `event` works
+    (target: $target:expr, $lvl:expr ) => (
+        $crate::enabled!(target: $target, $lvl, { "hint_message" })
+    );
+    (parent: $parent:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => (
+        $crate::enabled!(
+            target: module_path!(),
+            parent: $parent,
+            $lvl,
+            { message = format_args!($($arg)+), $($fields)* }
+        )
+    );
+    (parent: $parent:expr, $lvl:expr, $($k:ident).+ = $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            parent: $parent,
+            $lvl,
+            { $($k).+ = $($field)*}
+        )
+    );
+    (parent: $parent:expr, $lvl:expr, ?$($k:ident).+ = $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            parent: $parent,
+            $lvl,
+            { ?$($k).+ = $($field)*}
+        )
+    );
+    (parent: $parent:expr, $lvl:expr, %$($k:ident).+ = $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            parent: $parent,
+            $lvl,
+            { %$($k).+ = $($field)*}
+        )
+    );
+    (parent: $parent:expr, $lvl:expr, $($k:ident).+, $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            parent: $parent,
+            $lvl,
+            { $($k).+, $($field)*}
+        )
+    );
+    (parent: $parent:expr, $lvl:expr, %$($k:ident).+, $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            parent: $parent,
+            $lvl,
+            { %$($k).+, $($field)*}
+        )
+    );
+    (parent: $parent:expr, $lvl:expr, ?$($k:ident).+, $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            parent: $parent,
+            $lvl,
+            { ?$($k).+, $($field)*}
+        )
+    );
+    (parent: $parent:expr, $lvl:expr, $($arg:tt)+ ) => (
+        $crate::enabled!(target: module_path!(), parent: $parent, $lvl, { $($arg)+ })
+    );
+    ( $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => (
+        $crate::enabled!(
+            target: module_path!(),
+            $lvl,
+            { message = format_args!($($arg)+), $($fields)* }
+        )
+    );
+    ($lvl:expr, $($k:ident).+ = $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            $lvl,
+            { $($k).+ = $($field)*}
+        )
+    );


these are basically all for matching field values and messages, we should remove them.

hawkw · 2022-01-10T23:43:15Z

tracing/src/macros.rs

+    ($lvl:expr, ?$($k:ident).+, $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            $lvl,
+            { ?$($k).+, $($field)*}
+        )
+    );
+    ($lvl:expr, %$($k:ident).+, $($field:tt)*) => (
+        $crate::enabled!(
+            target: module_path!(),
+            $lvl,
+            { %$($k).+, $($field)*}
+        )
+    );
+    ($lvl:expr, ?$($k:ident).+) => (
+        $crate::enabled!($lvl, ?$($k).+,)
+    );
+    ($lvl:expr, %$($k:ident).+) => (
+        $crate::enabled!($lvl, %$($k).+,)
+    );


i don't think we would need the ? and % sigils, which control how values are recorded, if we never remove values.

guswynn · 2022-01-11T00:36:31Z

@hawkw I think the new commit implements what you asked
I am not 100% on what the difference between $k and $fields are in the macro, and how fieldset! works, so I may be passing the wrong field name through to the metadata, so itll need close eye. as mentioned, macro_rules! is not my forte

guswynn · 2022-01-11T00:46:11Z

I rebased on master and it still fails, weird

tracing/src/macros.rs

hawkw · 2022-01-11T21:20:30Z

tracing/src/macros.rs

+/// # Examples
+///
+/// ```rust
+/// use tracing::{enabled, Level};
+///
+/// # fn main() {
+/// #   if enabled!(Level::DEBUG, "Debug loggin") {
+/// #       // Do something expensive
+/// #   }
+/// # }


let's make sure we have some examples showing all of the following:

level only

level + target

level + field names

level + field names + target

also, it looks like the current example shows a "debug loggin" message, which shouldn't be necessary.

will wait on guswynn#1

`enabled!` is similar to `event!`, but never dispatches an event. It also allows a simplistic version of calling it, filling in a fake message in the metadata.

hawkw · 2022-01-13T17:28:40Z

tracing-core/src/metadata.rs

+    /// `enabled!` callsite. [`Collect`][`crate::collect::Collect`]s can assume
+    /// this `Kind` means they will never recieve a
+    /// full event with this [`Metadata`].
+    pub const HINT: Kind = Kind(KindInner::Hint);


One thought I had: a Subscriber may have a filter that chooses to enable only spans with a particular metadata, or only events with particular metadata. Having a HINT callsite limits specificity with the enabled! macro, as we don't get a way to ask "would you enable a span in this module with the fields foo and bar?" or "would you enable an event with those fields?"

I wonder if we want to change the internal representation of callsite kinds to permit a callsite to be a hint and a span or an event. We could do that by changing the hint state to be a separate flag, like:

pub struct Kind { // This is an `Option` so a hint generated by `enabled!` invocations that // don't specifically specify span or event aren't considered one or the // other. inner: Option<KindInner>, is_hint: bool, } impl Kind { pub fn is_span(&self) -> bool { // If the inner kind is `None`, this is an unspecific hint callsite, so // treat the callsite as both a span _and_ an event, in case the // subscriber would enable either matches!(self.inner, Some(KindInner::Span) | None) } pub fn is_event(&self) -> bool { matches!(self.inner, Some(KindInner::Event) | None) } pub fn is_hint(&self) -> bool { self.is_hint } }

Alternatively, if we wanted to avoid making the struct a bit larger, we could implement the same thing by changing the internal representation to bit flags:

pub struct Kind(u8); impl Kind { const HINT_BIT: u8 = 1 << 3; const EVENT_BIT: u8 = 1 << 1; const SPAN_BIT: u8 = 1 << 1; pub fn is_span(&self) -> bool { self.0 & Self::SPAN_BIT != 0 } pub fn is_event(&self) -> bool { self.0 & Self::EVENT_BIT != 0 } pub fn is_hint(&self) -> bool { self.0 & Self::HINT_BIT != 0 } // ... }

This might be a bit less clear, though.

In either case, we can address this in a follow-up branch, I think.

This is quite interesting! I agree follow-up branch is better for that kind of change!

hawkw · 2022-01-19T23:24:03Z

@davidbarsky any updates on the docs changes?

Set the `SYSLOG_IDENTIFIER` field on all events. I noticed that the subscriber didn't do this so far. ## Motivation The identifier is used with `journalctl -t`, and while it's normally better to filter by unit with `journalctl -u` the identifier is still nice for processes that are not started through systemd units. Upstream does this as well, see [here]: ![grafik](https://user-images.githubusercontent.com/224922/148660479-9525b21e-547f-4787-9bb7-db933963041a.png) `program_invocation_short_name` is a glibc variable which holds the file name of the current executable; I tried to replicate this behaviour in Rust. ## Solution Add a syslog identifier field to the subscriber, defaulting to the filename of the current executable, and write this value as `SYSLOG_IDENTIFIER` with every event. It's not written for spans, because it's a global value and inevitably the same for each span. [here]: https://github.com/systemd/systemd/blob/81218ac1e14b4b50b4337938bcf55cacc76f0728/src/libsystemd/sd-journal/journal-send.c#L270

Currently, the documentation states in a few places that the `tracing-futures` crate is required for asynchronous code to use `tracing`. This is no longer the case, as `tracing` provides the `Instrument` combinator for futures; `tracing-futures` is only needed for things defined in the `futures` crate, such as `Stream` and `Sink`. This branch updates the documentation so that it doesn't incorrectly state that `tracing-futures` is required.

hawkw

i went ahead and applied my docs suggestions, so this is good IMO pending CI

guswynn · 2022-01-28T18:51:59Z

@hawkw thanks for shepherding this through!

guswynn · 2022-01-28T18:52:23Z

now I probably need to look into how to backport it to 0.1

hawkw · 2022-01-28T18:57:44Z

@hawkw thanks for shepherding this through!

my pleasure, thanks for working on this!

now I probably need to look into how to backport it to 0.1

i'll take care about that, don't worry about it! :)

if you're interested in continuing to work on stuff, i think there might be a couple of follow-up changes to investigate, but i'm also happy to do them myself if you'd prefer:

add the option to test if a span with a specific name would be enabled (as i mentioned in https://github.com/tokio-rs/tracing/pull/1821/files/9395dc110f145f4936656d17e382d1d849e45fb8#diff-35444d6156072c5a3ac9451ab0ea0d02dc015d3acf41ccce5fe9880e0f483bab)
add the ability to construct hint callsites that also claim to be spans/events (implement enabled! #1821 (comment)), so you can specifically check if a span or event would be enabled (maybe the best UI for that is to have enabled!, span_enabled! and event_enabled! macros?)

tracing/src/macros.rs

## Motivation Closes: tokio-rs#1668 My usecase is different than the referenced "avoid doing something expensive to log": I want to guard turning on `debug` mode for an ffi'd library, based on some `target` that represents the "module" we care about. ## Solution The macro is very similar to `event!`, but adds a few simplistic cases, and generates ever so slightly different code (to return the correct value always. It also skips anything to do with `tracing-log`. I considered (and tried), to share the impl between `event!` and `enabled!`, but must confess I am not good at macros and got stuck. I think they are sufficiently different, where copied impls, is easier to read. We already manage Also, my project is on the crates.io version, so this would need to be backported to 0.1, I can help with that with guidance. Co-authored-by: Eliza Weisman <eliza@buoyant.io> Co-authored-by: David Barsky <me@davidbarsky.com>

guswynn · 2022-02-01T23:25:22Z

@hawkw If I find time this week I may look into those followups! as well as my own:

Query if a span/event/hint is enabled! for a specific layer. I need to think about this one for a bit

hawkw · 2022-02-01T23:28:26Z

Query if a span/event/hint is enabled! for a specific layer. I need to think about this one for a bit

I think this would require a separate API in tracing-subscriber --- it isn't going to be possible in the enabled! macro, which is defined in the tracing crate, which doesn't know about any concept of Layers.

Something like that could certainly be nice to have, although I think figuring out how to do it may require a great deal of work --- I would probably prioritize some of the smaller changes to the macro first, since they'll be easier to do, and would be nice to add before making a release with the enabled! macro.

Backports #1821 to `v0.1.x`. ## Motivation Closes: #1668 My usecase is different than the referenced "avoid doing something expensive to log": I want to guard turning on `debug` mode for an ffi'd library, based on some `target` that represents the "module" we care about. ## Solution The macro is very similar to `event!`, but adds a few simplistic cases, and generates ever so slightly different code (to return the correct value always. It also skips anything to do with `tracing-log`. I considered (and tried), to share the impl between `event!` and `enabled!`, but must confess I am not good at macros and got stuck. I think they are sufficiently different, where copied impls, is easier to read. We already manage Co-authored-by: Eliza Weisman <eliza@buoyant.io> Co-authored-by: David Barsky <me@davidbarsky.com>

This changes the `Kind` type to a bitflag, in order to represent callsites that are hints but also count as spans or events. The goal here is to allow variants of the `enabled!` macro that specifically check if a span would be enabled, or if an event would be enabled. See [this comment][1] for details. This does not actually implement the `enabled!` variants, just the `Kind` representation change. This way, we can add to the `enabled!` macro in a subsequent `tracing` release without having to change `tracing-core` again. I went with the bitflag representation rather than adding a bool to the `KindInner::Span` and `KindInner::Event` enum variants because it felt a bit simpler and maybe more performant, although I don't think it's particularly important to micro-optimize here. I'd consider changing this to an enum-based representation if people think it's significantly easier to understand. [1]: #1821 (comment)

This changes the `Kind` type to a bitflag, in order to represent callsites that are hints but also count as spans or events. The goal here is to allow variants of the `enabled!` macro that specifically check if a span would be enabled, or if an event would be enabled. See [this comment][1] for details. This does not actually implement the `enabled!` variants, just the `Kind` representation change. This way, we can add to the `enabled!` macro in a subsequent `tracing` release without having to change `tracing-core` again. I went with the bitflag representation rather than adding a bool to the `KindInner::Span` and `KindInner::Event` enum variants because it felt a bit simpler and maybe more performant, although I don't think it's particularly important to micro-optimize here. I'd consider changing this to an enum-based representation if people think it's significantly easier to understand. [1]: tokio-rs/tracing#1821 (comment)

Backports tokio-rs#1821 to `v0.1.x`. ## Motivation Closes: tokio-rs#1668 My usecase is different than the referenced "avoid doing something expensive to log": I want to guard turning on `debug` mode for an ffi'd library, based on some `target` that represents the "module" we care about. ## Solution The macro is very similar to `event!`, but adds a few simplistic cases, and generates ever so slightly different code (to return the correct value always. It also skips anything to do with `tracing-log`. I considered (and tried), to share the impl between `event!` and `enabled!`, but must confess I am not good at macros and got stuck. I think they are sufficiently different, where copied impls, is easier to read. We already manage Co-authored-by: Eliza Weisman <eliza@buoyant.io> Co-authored-by: David Barsky <me@davidbarsky.com>

This changes the `Kind` type to a bitflag, in order to represent callsites that are hints but also count as spans or events. The goal here is to allow variants of the `enabled!` macro that specifically check if a span would be enabled, or if an event would be enabled. See [this comment][1] for details. This does not actually implement the `enabled!` variants, just the `Kind` representation change. This way, we can add to the `enabled!` macro in a subsequent `tracing` release without having to change `tracing-core` again. I went with the bitflag representation rather than adding a bool to the `KindInner::Span` and `KindInner::Event` enum variants because it felt a bit simpler and maybe more performant, although I don't think it's particularly important to micro-optimize here. I'd consider changing this to an enum-based representation if people think it's significantly easier to understand. [1]: tokio-rs#1821 (comment)

guswynn requested review from carllerche, davidbarsky, hawkw and a team as code owners January 7, 2022 17:44

guswynn force-pushed the enabled branch 2 times, most recently from f82d63e to 3be5c13 Compare January 7, 2022 17:53

implement enabled!

0b4c3ac

`enabled!` is similar to `event!`, but never dispatches an event. It also allows a simplistic version of calling it, filling in a fake message in the metadata.

guswynn force-pushed the enabled branch from 3be5c13 to 0b4c3ac Compare January 7, 2022 17:56

hawkw requested changes Jan 10, 2022

View reviewed changes

simplify the macro

12474e1

guswynn force-pushed the enabled branch from 8e983cf to 12474e1 Compare January 11, 2022 00:35

remove new event methods

5ccc947

guswynn and others added 2 commits January 11, 2022 08:40

fix Kind::HINT's doc's

289bfed

Merge branch 'master' into enabled

04b7fcc

hawkw reviewed Jan 12, 2022

View reviewed changes

guswynn added 5 commits January 13, 2022 08:16

implement enabled!

7d5831d

`enabled!` is similar to `event!`, but never dispatches an event. It also allows a simplistic version of calling it, filling in a fake message in the metadata.

simplify the macro

b3d042d

remove new event methods

ac87e42

fix Kind::HINT's doc's

9b09230

simplify dot cases

7f9aee9

guswynn force-pushed the enabled branch from 04b7fcc to 7f9aee9 Compare January 13, 2022 16:16

hawkw reviewed Jan 13, 2022

View reviewed changes

davidbarsky and others added 3 commits January 24, 2022 18:17

Merge branch 'master' into enabled

dee8846

fix wrong callsite kind for enabled!

9cb95d5

hawkw approved these changes Jan 28, 2022

View reviewed changes

hawkw enabled auto-merge (squash) January 28, 2022 18:51

Merge branch 'master' into enabled

f993288

auto-merge was automatically disabled January 28, 2022 18:51
Pull Request is not mergeable

hawkw reviewed Jan 28, 2022

View reviewed changes

tracing/src/macros.rs Outdated Show resolved Hide resolved

Update tracing/src/macros.rs

fbe5f84

hawkw enabled auto-merge (squash) January 28, 2022 19:00

bleh rustfmt

3cf628a

hawkw merged commit 71da8a5 into tokio-rs:master Jan 28, 2022

guswynn mentioned this pull request Feb 1, 2022

tracing: backport "implement enabled!" #1883

Merged

This was referenced Feb 3, 2022

core: change metadata::Kind to a bitflag #1891

Merged

tracing: Add span- and event-specific enabled! variants #1892

Closed

guswynn deleted the enabled branch February 4, 2022 17:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

implement `enabled!` #1821

implement `enabled!` #1821

guswynn commented Jan 7, 2022

guswynn commented Jan 7, 2022

hawkw commented Jan 10, 2022

hawkw left a comment

hawkw Jan 10, 2022

guswynn Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

guswynn Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

hawkw Jan 10, 2022

guswynn commented Jan 11, 2022

guswynn commented Jan 11, 2022

hawkw Jan 11, 2022

guswynn Jan 13, 2022

hawkw Jan 13, 2022

guswynn Jan 13, 2022

hawkw commented Jan 19, 2022

hawkw left a comment

guswynn commented Jan 28, 2022

guswynn commented Jan 28, 2022

hawkw commented Jan 28, 2022

guswynn commented Feb 1, 2022

hawkw commented Feb 1, 2022 •

edited

Loading

	/// `enabled!` callsite. [`Collect`][`crate::collect::Collect`]'s can assume
	/// `enabled!` callsite. [`Collect`][`crate::collect::Collect`]s can assume

implement enabled! #1821

implement enabled! #1821

Conversation

guswynn commented Jan 7, 2022

Motivation

Solution

guswynn commented Jan 7, 2022

hawkw commented Jan 10, 2022

hawkw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guswynn commented Jan 11, 2022

guswynn commented Jan 11, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hawkw commented Jan 19, 2022

hawkw left a comment

Choose a reason for hiding this comment

guswynn commented Jan 28, 2022

guswynn commented Jan 28, 2022

hawkw commented Jan 28, 2022

guswynn commented Feb 1, 2022

hawkw commented Feb 1, 2022 • edited Loading

implement `enabled!` #1821

implement `enabled!` #1821

hawkw commented Feb 1, 2022 •

edited

Loading