Argument matcher for a struct with a field with non-default value about nsubstitute

[alexandrnikitin]

@eValker Thank you for the issue and the great repro. Yes, that's a bug indeed.

It happens because when we check the provided argument specification in

NSubstitute/src/NSubstitute/Core/Arguments/ArgumentSpecificationCompatibilityTester.cs

Lines 12 to 22 in f470b5d

	public bool IsSpecificationCompatible(IArgumentSpecification specification, object? argumentValue, Type argumentType)
	{
	var typeArgSpecIsFor = specification.ForType;
	return AreTypesCompatible(argumentType, typeArgSpecIsFor)
	&& IsProvidedArgumentTheOneWeWouldGetUsingAnArgSpecForThisType(argumentValue, typeArgSpecIsFor);
	}
	private bool IsProvidedArgumentTheOneWeWouldGetUsingAnArgSpecForThisType(object? argument, Type typeArgSpecIsFor)
	{
	return _defaultChecker.IsDefault(argument, typeArgSpecIsFor);
	}

we compare the provided argument with its default value

NSubstitute/src/NSubstitute/Core/DefaultForType.cs

Lines 29 to 50 in f470b5d

	private object DefaultInstanceOfValueType(Type returnType)
	{
	// Performance optimization for the most popular types.
	if (returnType == typeof(bool))
	{
	return BoxedBoolean;
	}
	if (returnType == typeof(int))
	{
	return BoxedInt;
	}
	if (returnType == typeof(long))
	{
	return BoxedLong;
	}
	if (returnType == typeof(double))
	{
	return BoxedDouble;
	}
	return Activator.CreateInstance(returnType)!;
	}

Where we use Activator.CreateInstance to create an instance of the specified type. It in its turn calls the default constructor of the struct which initializes the field with the default value not the specified one. That's why it doesn't consider the provided argument spec and throws RedundantArgumentMatcherException

It looks like a fix would be to propagate the matchArgs from ArgumentSpecificationsFactory down to the call stack and don't compare default values if it's MatchArgs.Any
https://github.com/nsubstitute/NSubstitute/blob/f470b5de58a0bb1f41157b7ce6210e35dd4f977f/src/NSubstitute/Core/Arguments/ArgumentSpecificationsFactory.cs#L49C16-L51

But I don't remember that part of code and frankly don't understand why we need to compare the provided spec with the default value of its type. @dtchepak @zvirja maybe you remember that? Is there a better fix?

[agarbutt]

I am specifically encountering this behavior as well while exploring strongly typed ids (defined as structs wrapping the supporting value) in my code base.

It's not obvious if there is a work-around without changing how we would model these values.

[dtchepak]

Hi @alexandrnikitin 👋 😄

But I don't remember that part of code and frankly don't understand why we need to compare the provided spec with the default value of its type. @dtchepak @zvirja maybe you remember that? Is there a better fix?

IIRC we looked at default values to try to match up enqueued arg matchers with the actual args passed to members. (I'm not sure what the other options are there?)

The instance we return from Arg.* uses DefaultValueContainer. Can we use the same mechanism instead of Activator.CreateInstance?