Rust tests need to verify return type, otherwise my solution works (return Cheat type, which equals everything).

I updated the Rust tests, removing all cases where b <= a. The previously enforced behavior was unintuitive.
Other languages do not test b < a either, as the behavior is not specified in the description.

Good work! One small oddity: for inputs like "-0", the function cannot return "-0/1"; it must remove the negative sign. I'm not sure if that was intended. You might want to clarify in the description, or allow "-0/1", or completely remove any test cases with "-0".

@JohanWiltink:

the tests seem limited to m = 4 so that's practically a constant.

The description was misleading, I clarified it. The intention of "Tests use large m," was to test high values in m, not a large set size.

I specifically included large values in m, because they can cause overflow problems. My first naive Rust solution panicked on large m values.

Testing large m set size does not seem necessary.

I think requiring such extreme performance is overdoing it just a little - that seems to come with 3 kyu and "implement advanced requirements in a scalable fashion".

My intention is to allow any O(n) solution, and deny the naive solution which repeatedly scans further and further back into the sequence. Balancing the correct amount of tests to achieve this can be difficult, especially when execution time varies based on server load and language version.

the slice index must be usize, not i32

https://doc.rust-lang.org/std/slice/trait.SliceIndex.html

Should remove the test case for (4, 1), since a divisor is guaranteed to exist.

You need chars() to safely iterate UTF characters of a str. Strings are always UTF-8 encoded, so accessing the bytes directly would be problematic. The collect() at the end consumes the Iterator into a String.

For better functional composition, a more flexible signature would be:

fn no_space(x: impl IntoIterator<Item=char>) -> impl Iterator<Item=char>

This way you could pass any iterable into the function (including str.chars()), and chain the function lazily, without allocating a String for output.