Wrongly detected spelling mistake resolves when command is re-run

[cmichi]

Describe the bug

This run failed: https://gitlab.parity.io/parity/ink/-/jobs/1021515 with this error:

error: spellcheck(Hunspell)
    --> /builds/parity/ink/crates/lang/ir/src/ir/item_impl/callable.rs:185
[2021-07-20T09:04:18Z INFO  cargo_spellcheck::action] ❌ /builds/parity/ink/crates/lang/ir/src/ir/item_impl/callable.rs : 1
 185 |  - the callable's identifier `i`
     |        ^^^^^^^^^^
     |   Possible spelling mistake found.

The dictionary contains callable/MS though.

I re-ran the job and it succeeded on that retry: https://gitlab.parity.io/parity/ink/-/jobs/1021549.

Expected behavior

Runs of cargo spellcheck should be idempotent.

Please complete the following information:

• System: Ubuntu 20.04 LTS
• Obtained: cargo install
• Version: 0.8.10
  The command executed is

$ cargo spellcheck check -vvv --cfg=.config/cargo_spellcheck.toml --checkers hunspell --code 1

Maybe the -vvv provides more information now for you to debug this? We added the verbosity flags after prior occurrences of this error contained too little information.

[drahnr]

The detail of the bugreport is awesome, I have one small request: tack another -v into the execution, which will add a whole lot of debug output (but unlike trace still keep it tractable). Currently I can't do much since the output is essentially showing the rules being loaded and that's it.

I think that's the main TODO here, better balance of info, debug, and trace logs

[drahnr]

Note that with v0.8.10 the -r flag works as expected, so the bash-base for loops are not necessary anymore.

[cmichi]

I just encountered this issue again:

• Failed run: https://gitlab.parity.io/parity/ink/-/jobs/1043859
• Succeeded run on first retry: https://gitlab.parity.io/parity/ink/-/jobs/1043897

The word is in the dictionary here.

[drahnr]

Thank you! This proves that callable.rs is picked up by both runs, and is processed by both runs which falsifies my initial suspicion. This points pretty much into a hunspell-rs wrapping bug, a hunspell usage bug or an internal hunspell bug.

[drahnr]

So it seems this was caused by -r flag which follows mod foo; declarations. With the changes in paritytech/polkadot#3992 this should be resolved for good. Re-open if that assumption turns out to be wrong.