Work around rust-analyzer false-positive type errors

[Zalathar]

rust-analyzer incorrectly reports two type errors in debug.rs:

expected &dyn Display, found &i32
expected &dyn Display, found &i32

This is due to a known bug in r-a: (rust-lang/rust-analyzer#11847).

In these particular cases, changing &0 to &0i32 seems to be enough to avoid the bug.

[rustbot]

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[oli-obk]

I'm not sure it's a good idea to work around bugs in our tools, but I'm not against it on principle.

[Zalathar]

Looking again at these call sites, I don’t think there’s any particular reason why the argument has to be the number zero, so it may be preferable to replace it with some opaque string instead.

[apiraino]

How do people feel about this patch? Trying to figure out if we want to land this or rather should be tackled by r-a. thanks!

[Zalathar]

A few other pieces of context:

• The affected method has a few other call sites that also trigger the same issue (with a dummy 0 argument). This PR only touches the coverage-related ones because that’s what affects me personally, but in principle the other sites could get the same treatment.
• The argument in question is only used as part of the filename of a dump file, so the affected code is pretty low-stakes overall.

[jackh726]

Honestly, this is such a small, semantically equivalent change that ultimately doesn't hurt readability, so I'm going to r+ it.

In general though, I agree with oli that we shouldn't try to work around tooling issues, particularly if they impact readability or maintainability.

@bors r+ rollup

[bors]

📌 Commit 5494eec has been approved by jackh726

It is now in the queue for this repository.