These types make heavy use of generics and combined types.
Instantiating string representation methods for all possibilities is unecesssary and slows down compilation.
Code changes for https://github.com/icy-arctic-fox/spectator/issues/47 caused a drastic increase in compilation times.
This improves compilation times by splitting concerns for arguments.
In one case, arguments are used for matching.
In the other, arguments are captured for comparison.
The second case has been moved to a FormalArguments class.
Theoretically, this reduces the complexity and combinations the compiler might be iterating.
For some reason, line 421 (the responds to call check) excluded the stub's call type.
Luckily this line doesn't seem to be necessary anymore.
Removed the unecessary quick check.
The tests from spec/spectator/mocks/double_spec:88-96 were failing when they're the only tests in the file.
The non-matching stub wouldn't raise.
Stepping through, attempting to access the value would segfault.
This is because it accessed a stub with String instead of its real Int32 type.
Removing the aforementioned check fixes this.
Undefined double methods were reporting splat arguments, which is technically correct.
But for output in these cases, it makes more sense to show the exact calling args.
In Crystal 1.6, a segfault would occur in the spec spec/spectator/mocks/lazy_double_spec.cr:238
I suspect this is a Crystal bug of some kind, but can't reduce it.
The methods produced by `method_missing` don't have a return type including Symbol.
Symbol is excluded from the union of return types (Int32 | String | Nil).
The program segfaults when calling a method on the actual value, which is a symbol.
It ultimately crashes when producing a failure message, which indicates the value it tested doesn't equal the expected value (a symbol of the same value).
Avoid this issue by preventing stubs on undefined/untyped methods.
When defining a matcher outside of the `Spectator` module (custom matcher), `Value(ExpectedType)` can't be resolved.
I suspect this is a Crystal compiler bug, since a derived class should not affect lookups of parent classes like this.
Require statements are added to (hopefully) ensure `Spectator::Value` is defined for the initializer.
Related to https://github.com/icy-arctic-fox/spectator/issues/46
BUG: trying to upcast Nil (Crystal::NilType) <- NoReturn (Crystal::NoReturnType) (Exception)
from /crystal/src/compiler/crystal/codegen/cast.cr:668:5 in 'upcast_distinct'
from /crystal/src/compiler/crystal/codegen/cast.cr:523:15 in 'upcast'
from /crystal/src/compiler/crystal/codegen/codegen.cr:1369:11 in 'accept'
from /crystal/src/compiler/crystal/codegen/codegen.cr:2274:9 in 'visit'
from /crystal/src/compiler/crystal/syntax/visitor.cr:27:12 in 'accept'
...
This effectively allows stubs to be placed on the `new` method for types.
A strange issue arose when the keyword was allowed.
The compiler failed to resolve the Stub type from the Double initializer.
The error trace goes through null_double_spec.cr.
Running just that spec file confirms the issue is there, but running other individual files doesn't produce the error.
As a workaround, I've put the full path of Stub in the initializer.
Without this, mocked structs were not getting their stubs applied.
An unintended side-effect is the tap shows up in recorded calls.
This seems to be harmless, but might need to be revisited.
