workaround an issue that causes function arguments to show up as if they are uncovered

[alex]

rust-lang/rust#86972 describes this issue in some detail and links to a minimal reproducer

making this change, and this change alone, resolves the coverage issues

[davidhewitt]

Hmmm, interesting.

So if I understand correctly, we've generated a branch which spans the argument, however in your tests it's not covered. You (or any other user doing similar things) would have to invoke every argument with incorrect types to achieve full coverage.

I think it's reasonable to adjust this in this way. Can we add a CHANGELOG message please, in case others are also noticing this behaviour?

I am curious though: if branches like this are a problem, I wonder why you're not having issues with the branching around default arguments slightly further down the file?

pyo3/pyo3-macros-backend/src/params.rs

Lines 244 to 260 in 8107c86

	let arg_value_or_default = match (spec.default_value(name), arg.optional.is_some()) {
	(Some(default), true) if default.to_string() != "None" => {
	quote_arg_span! { #arg_value.map_or_else(|| Ok(Some(#default)), |_obj| #extract)? }
	}
	(Some(default), _) => {
	quote_arg_span! { #arg_value.map_or_else(|| Ok(#default), |_obj| #extract)? }
	}
	(None, true) => quote_arg_span! { #arg_value.map_or(Ok(None), |_obj| #extract)? },
	(None, false) => {
	quote_arg_span! {
	{
	let _obj = #arg_value.expect("Failed to extract required method argument");
	#extract?
	}
	}
	}
	};

[alex]

I have really no explanation for why it's not impacting all of these spans or anything like that.

I'll add the changelog entry.

[davidhewitt]

👍 I guess we can always tweak further if other users find other cases. Thanks very much for fixing.

[alex]

Thanks for the quick merge!