minor: suppress 'clippy::approx_constant' lint in test case

[danieleades]

suppresses a false positive clippy lint

[HKalbasi]

This repository doesn't accept #[allow(clippy::*)] attributes and in general doesn't consider all clippy lints helpful. See https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/style.md#clippy

[danieleades]

This repository doesn't accept #[allow(clippy::*)] attributes and in general doesn't consider all clippy lints helpful. See https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/style.md#clippy

I did read up on those after submitting this PR. it's... an odd position. Occasionally clippy will suggest changes for performance/correctness reasons. Having clippy error out early over unsuppressed false positives obscures these cases during local development.

Not to mention there's quite a few commits that seem to be for addressing clippy lints. Eg, d3dbf9c

[lnicola]

We take PRs for selective fixes which improve performance or simplify the code, and we have a cargo alias which runs clippy for categories of lints. I don't think we're at risk here to duplicate mathematical constants, we're not that kind of app, and there's not much point in fixing these in RA.

[HKalbasi]

In this case there is no need for that test to use pi, you can suppress the lint by using 0.123456789 instead of pi.

[danieleades]

In this case there is no need for that test to use pi, you can suppress the lint by using 0.123456789 instead of pi.

intentionally changing perfectly reasonable code in order to suppress a clippy false positive hardly seems better than explicitly suppressing the lint, no?

If it would get this merged i'm happy to do it, but i'm struggling to understand how it's better

[HKalbasi]

The benefit is that it wouldn't make noise for other readers. But it's still an arbitrary change to make clippy happy, which is against the clippy policy.

[Veykril]

We might want to revisit the clippy policy at some point. I personally would like for us to enable clippy on rust-analyzer at some point, but only once we are able to specify the lints we are interested in in a project-wide place, which to my knowledge is still not really possible.

[lnicola]

CC #13865

[danieleades]

i've updated this PR to use a different arbitrary decimal that clippy won't complain about.

I understand the concerns about this change, and in particular the purist perspective that this violates the clippy policy.

On the other hand, from a pragmatic perspective, this change provides a small practical benefit with no real downside.

I leave it for the brains trust to decide what to do with it

[Veykril]

@bors r+

[bors]

📌 Commit b196e5b has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit b196e5b with merge ba204ef...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing ba204ef to master...