-
Notifications
You must be signed in to change notification settings - Fork 411
Replace arc.clone()
with Arc::clone
and reject the former in clippy (plus enforce clippy in tests)
#3851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace arc.clone()
with Arc::clone
and reject the former in clippy (plus enforce clippy in tests)
#3851
Conversation
TheBlueMatt
commented
Jun 12, 2025
`arc.clone()` leaves the code somewhat ambiguous to whether we're doing an expensive deep-clone operation or if we're doing a (relatively) cheap pointer-copy-and-atomic-increment operation. More importantly, it leaves entirely unclear what the semantics of the object we just created are - does updating it update the original or leave it be? Thus, here, we replace `arc.clone()` calls with `Arc::clone()` in `lightning-net-tokio/src/lib.rs`
`arc.clone()` leaves the code somewhat ambiguous to whether we're doing an expensive deep-clone operation or if we're doing a (relatively) cheap pointer-copy-and-atomic-increment operation. More importantly, it leaves entirely unclear what the semantics of the object we just created are - does updating it update the original or leave it be? Thus, here, we replace `arc.clone()` calls with `Arc::clone()` in `lightning-background-processor/src/lib.rs`
`arc.clone()` leaves the code somewhat ambiguous to whether we're doing an expensive deep-clone operation or if we're doing a (relatively) cheap pointer-copy-and-atomic-increment operation. More importantly, it leaves entirely unclear what the semantics of the object we just created are - does updating it update the original or leave it be? Thus, here we require `Arc::clone` via clippy enforcement in CI
In a coming commit we'll enable `clippy` linting in our test code. However, there's some things we do in tests (which we might reasonably do in non-test code in the future) that clippy is unhappy with, which we explicitly allow here.
In a coming commit we'll enable `clippy` linting in our test code. Here we prepare for this by addressing the lints we'll enforce in test codein the `lightning` crate.
👋 Thanks for assigning @tnull as a reviewer! |
arc.clone()
with Arc::clone
and reject the former in clippyarc.clone()
with Arc::clone
and reject the former in clippy (plus enforce clippy in tests)
In a coming commit we'll enable `clippy` linting in our test code. Here we prepare for this by addressing the lints we'll enforce in test code in remaining crates.
`arc.clone()` leaves the code somewhat ambiguous to whether we're doing an expensive deep-clone operation or if we're doing a (relatively) cheap pointer-copy-and-atomic-increment operation. More importantly, it leaves entirely unclear what the semantics of the object we just created are - does updating it update the original or leave it be? Thus, here, we replace `arc.clone()` calls with `Arc::clone()` in `lightning-background-processor` tests.
`arc.clone()` leaves the code somewhat ambiguous to whether we're doing an expensive deep-clone operation or if we're doing a (relatively) cheap pointer-copy-and-atomic-increment operation. More importantly, it leaves entirely unclear what the semantics of the object we just created are - does updating it update the original or leave it be? Thus, here, we replace `arc.clone()` calls with `Arc::clone()` in remaining tests.
6c06771
to
211871b
Compare
211871b
to
0dcea98
Compare
Disabled the broken shellcheck lint:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
-A clippy::io_other_error `# to be removed once we hit MSRV 1.74` | ||
|
||
CLIPPY() { | ||
# shellcheck disable=SC2086 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we shouldn't just fix it instead of disabling the check, but not going to block this because of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lack of quotes is deliberate, we need to pass multiple things to clippy
via one argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, wait, rustfmt
is unhappy.
Clippy points out that "format specifiers have no effect on `format_args!()`", i.e. that our attempt to fix the log context width to 55 chars doesn't do anything because its applied to the result of `format_args`ing the context. This appears to have broken when we optimized out a previous `format`, which we revert here.
Now that we've fixed many of the lints clippy cares about for our test code, switch to enforcing the lints in `--tests` as well. We disable a few lints that require substantial number of changes to our existing tests, sadly, though they'd probably be good changes to make at some point.
0dcea98
to
07590e4
Compare
Fixed. |
Can probably be landed with one ACK, the diff is just:
|