Rust Diamond excersise tests pass locally but online check fails #71

Exercism Support
1

Hi,

i have opened the issue: Rust Diamond excersise tests pass locally but online check fails · Issue #71 · exercism/rust-test-runner · GitHub

Thank you in advance! :slight_smile:

2

I solved the excercise and I’m aware what was the problem.
But I can’t understand why the test were passing locally… :thinking:

3

I am not a rust developer but here are the 2 causes which is the most common once.

  1. The exercise is broken. This is although quite unlikly

  2. The code isnt compatiable with the version the test runner is running. In most cases the test runner runs an older version. The rust one runs on 1.66. And it is quite common that the test runner doesnt run on the latest version. And this is the most likely cause aswell.

4

@denizeve Please post direct quotes rather than screenshots in the future. That makes it much easier for others to try your code.

@Meatball I would have expected incompatible code to not compile, but these tests report panicks. Incompatibilities to me seem unlikely anyway, as it’s Rust. Still…

@denizeve what does rustc --version report? You already said it’s 1.67.

5

Well as I said I am not a rust developer, but you are right about that, I just noticed they used a different version(1.67) compared to the test-runner so the “easist” way to roll out that the rust version is causing this would be to install 1.66 localy and test run the code.

6

First of all, thank you @MatthijsBlom and @Meatball.

I found what was the catch. It wasn’t the version (I tried both 1.66.0 and 1.66.1).

The thing is: I was running the tests in –release mode.

TL;DR
From Rust’s docs:

When you’re compiling in release mode with the --release flag, Rust does not include checks for integer overflow that cause panics.

Well, I learned a new thing today :slight_smile:

7

I am not surprised you avoided panicks by compiling with --release, but I am surprised that you managed to produce correct results using (apparently) faulty logic.

8

Results were correct by mere luck.
Because the last loop iteration (where the panics happen) was not affecting the result, but only adjusting some variables for subsequent iterations.

I published the solution, so you can check it out.
1st solution iteration fails, and in 2nd I have put the control condition (ln 24).

p.s. That solution itself is a lousy one… I plan to make it much better :wink: