core: impl field::Value for Option<T>

[bryanburgers]

I'm very interested in #1393 getting merged. Yep, I'm aware that the Valuable work may supersede this, but in the mean time this would be a huge improvement for how we use tracing.

Based on this comment #1393 (review) by @hawkw it looks like the only thing holding up #1393 is some tests? If so, here is one test. Let me know what other tests you'd like to see and I'll get them added.

I wasn't quite sure how to assert that the mock did not record fields none_str, none_bool, etc.

[bryanburgers]

Ah yeah, I also rebased it onto master, if that matters.

[hawkw]

Ugh...the CI failure isn't your fault, it looks like a recent release of a dependency (http) broke MSRV compatibility...

[bryanburgers]

Ugh...the CI failure isn't your fault, it looks like a recent release of a dependency (http) broke MSRV compatibility...

OK, I won't worry about that one. (The force push was to fix a legitimate style test failure.)

[bryanburgers]

Actually, now that I think about it, does it make more sense to PR this against the v0.1.x branch?

I'm guessing master will turn into 0.2? So yeah, probably makes sense to use the 0.1 branch.

If that makes sense, I'll rebase tomorrow morning.

[CAD97]

Ugh...the CI failure isn't your fault, it looks like a recent release of a dependency (http) broke MSRV compatibility...

hyperium/http#481, includes context on (deliberate) MSRV bump

[bryanburgers]

Rebased to PR off of v0.1.x because this change seems appropriate to get into the 0.1.x line, but may be completely unnecessary in the 0.2.x line if 0.2.x comes with full Valuable support.

[hawkw]

Thanks, this looks good to me overall!

Rebased to PR off of v0.1.x because this change seems appropriate to get into the 0.1.x line, but may be completely unnecessary in the 0.2.x line if 0.2.x comes with full Valuable support.

Yes, I think basing this on v0.1.x seems correct; the valuable support on 0.2 will make this unnecessary (and may, in fact, result in a conflicting impl, since I believe Options already have Valuable impls in valuable).

Based on this comment #1393 (review) by @hawkw it looks like the only thing holding up #1393 is some tests? If so, here is one test. Let me know what other tests you'd like to see and I'll get them added.

Yeah, the tests were kind of a blocker because I thought it was important that code with expected uses of this API actually compiles and works as expected. :) I think we probably also want to add tests for references to Options, for that reason.

A couple other things that would be nice to do, but can be done in follow-up branches:

• it's probably worth adding examples of recording Option values in the docs, maybe in this section?

  tracing/tracing/src/lib.rs

  Line 242 in e455367

  //! ### Recording Fields

• Also, we'll want to add support for Option values in the instrument attribute, somewhere around here:

  tracing/tracing-attributes/src/lib.rs

  Lines 1091 to 1142 in e455367

  	/// Array of primitive types which should be recorded as [RecordType::Value].
  	const TYPES_FOR_VALUE: &'static [&'static str] = &[
  	"bool",
  	"str",
  	"u8",
  	"i8",
  	"u16",
  	"i16",
  	"u32",
  	"i32",
  	"u64",
  	"i64",
  	"f32",
  	"f64",
  	"usize",
  	"isize",
  	"NonZeroU8",
  	"NonZeroI8",
  	"NonZeroU16",
  	"NonZeroI16",
  	"NonZeroU32",
  	"NonZeroI32",
  	"NonZeroU64",
  	"NonZeroI64",
  	"NonZeroUsize",
  	"NonZeroIsize",
  	"Wrapping",
  	];
  	/// Parse `RecordType` from [syn::Type] by looking up
  	/// the [RecordType::TYPES_FOR_VALUE] array.
  	fn parse_from_ty(ty: &syn::Type) -> Self {
  	match ty {
  	syn::Type::Path(syn::TypePath { path, .. })
  	if path
  	.segments
  	.iter()
  	.last()
  	.map(|path_segment| {
  	let ident = path_segment.ident.to_string();
  	Self::TYPES_FOR_VALUE.iter().any(|&t| t == ident)
  	})
  	.unwrap_or(false) =>
  	{
  	RecordType::Value
  	}
  	syn::Type::Reference(syn::TypeReference { elem, .. }) => {
  	RecordType::parse_from_ty(&*elem)
  	}
  	_ => RecordType::Debug,
  	}
  	}

  That way, a function with #[instrument] can record any Option arguments as typed Option values when the value inside the option implements Value.

But, those can both be done in subsequent changes, so we can get this merged and move forward!

[hawkw]

i went ahead and applied my test suggestions, and once CI passes, we can merge this, and make the follow-up changes in other branches!

[CAD97]

Would it make sense to use Empty for the None case? Or does that just end up with the same result?