For some reason, after I fixed my code, it no longer functioned properly. The problem was a for loop that seemed to cause the loop to progress as if the continue keyword was called. Does anyone know why this happens?
You will have to run the code on your local machine, however, as the json crate is not supported in the playground (nor is network access).
UPDATE: I have found that adding one item to the variables HashMap seems to fix the issue, but if there is more than one item, all of the code below the loop seems to repeat the same number of times as their items in the HashMap. Is this a bug in Rust? Or am I just missing something very obvious? Also, this bug acts diffrently in the stable version vs. the nightly version.
I think you shared the wrong playground (it looks like the one from the other thread, before the fix suggested in the last comment).
If the only difference is the one-line fix, it's probably because you're iterating over your varibles and re-evaluating the command every time within the iteration loop, which makes no sense. Do all your replacement first, then process the command.
Untested besides compiling:
- for (&ref key, &ref value) in varibles.clone().iter() {
+ for (key, value) in varibles.iter() {
println!("looking for {key}");
if commands.contains(&format!("${key}").as_str()) {
let index = commands.iter().position(|&r| r == key).unwrap();
commands[index] = value
}
+ } // end the iteration loop here
if allowed_commands.contains(&commands[0].to_string()) {
[...]
} else {
println!("spacetraders: {}: command not found", commands[0]);
}
- } // and not here
Guess I misplaced a bracket somewhere. But why does it act differently between stable and nightly? On stable if I run the command set h 69 then run echo $h it would print
$h
69
On nightly it would print
69
69
Oh, I probably do know. Iteration order of the HashMap differed between the two compilations, and on nightly it replaced $h first, and on stable it replaced $h second.
1 Like