A proc on the left side of === calls itself passing in the right side.
This causes typing issues and is easier to avoid for now.
Procs arguments are compared with standard equality (==) instead of case-equality (===).
Remove `is_a?` check on line 425.
Replace with alternate logic that achieves the same thing.
The `{{type}}` in `is_a?` was causing a compiler bug.
I'm unsure of the root cause, but this works around it.
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.
These may be readded later.
Right now they're failing because the GitHub issue 44 spec changes the behavior of Process.run.
The changes made by that spec shouldn't leak, but to fix correctly requires substantial changes.
These runtime tests provide little value right now and slow down testing.
