Apply docs suggestions from code review

Co-authored-by: David Barsky <me@davidbarsky.com>

Author: hawkw

tracing-subscriber/src/filter/layer_filters.rs

@@ -92,9 +92,9 @@ pub struct FilterFn<
 /// **Note**: Currently, the [`Registry`] type provided by this crate is the
 /// **only** [`Subscriber`] implementation capable of participating in per-layer
 /// filtering. Therefore, the `FilterId` type cannot currently be constructed by
-/// user code. In the future, new APIs will be added to `tracing-subscriber` to
-/// allow user-implemented [`Subscriber`]s to also participate in per-layer
-/// filtering. When those APIs are added, user subscribers will be responsible
+/// code outside of `tracing-subscriber`. In the future, new APIs will be added to `tracing-subscriber` to
+/// allow non-Registry [`Subscriber`]s to also participate in per-layer
+/// filtering. When those APIs are added, subscribers will be responsible
 /// for generating and assigning `FilterId`s.
 ///
 /// [`Filter`]: crate::layer::Filter
@@ -122,7 +122,7 @@ pub(crate) struct FilterMap {
 /// thread.
 ///
 /// When `Filtered::enabled` is called, the filter will set the bit
-/// corresponding to its ID if it will disable the event/span being
+/// corresponding to its ID if the filter will disable the event/span being
 /// filtered. When the event or span is recorded, the per-layer filter will
 /// check its bit to determine if it disabled that event or span, and skip
 /// forwarding the event or span to the inner layer if the bit is set. Once
@@ -132,19 +132,18 @@ pub(crate) struct FilterMap {
 ///
 /// This is also read by the `Registry`, for two reasons:
 ///
-/// 1. When filtering a span, the registry must store the `FilterMap`
+/// 1. When filtering a span, the Registry must store the `FilterMap`
 ///    generated by `Filtered::enabled` calls for that span as part of the
 ///    span's per-span data. This allows `Filtered` layers to determine
-///    whether they previously disabled a given span, and avoid showing it
+///    whether they had previously disabled a given span, and avoid showing it
 ///    to the wrapped layer if it was disabled.
 ///
-///    This is the mechanism that allows `Filtered` layers to also filter
-///    out the spans they disable from span traversals (such as iterating
-///    over parents, etc).
+///    This allows `Filtered` layers to also filter out the spans they
+///    disable from span traversals (such as iterating over parents, etc).
 /// 2. If all the bits are set, then every per-layer filter has decided it
 ///    doesn't want to enable that span or event. In that case, the
-///    `Registry`'s `enabled` method will return `false`, so that we can
-///    skip recording it entirely.
+///    `Registry`'s `enabled` method will return `false`, so that
+///     recording a span or event can be skipped entirely.
 #[derive(Debug)]
 pub(crate) struct FilterState {
     enabled: Cell<FilterMap>,
@@ -273,7 +272,7 @@ where
         let interest = self.filter.callsite_enabled(metadata);
 
         // If the filter didn't disable the callsite, allow the inner layer to
-        // register it --- since `register_callsite` is also used for purposes
+        // register it — since `register_callsite` is also used for purposes
         // such as reserving/caching per-callsite data, we want the inner layer
         // to be able to perform any other registration steps. However, we'll
         // ignore its `Interest`.