New lint: Suggests using `Cell<T: Copy>` instead of `RefCell<T: Copy>` by qdot3 · Pull Request #17522 · rust-lang/rust-clippy

qdot3 · 2026-08-08T01:03:53Z

Implementation of #17380

This lint suggests using Cell instead of RefCell for Copy types. RefCell avoids cloning, but it introduces additional memory overhead and runtime checks, which are not worthwhile for Copy types.

Scope

Field definitions
Type aliases
Input/output types of functions, methods, and trait methods (definition site)
Associated types
Simple let statements (e.g., let _ = RefCell::new(1))
All of the above when appearing inside tuples or arrays

Out of scope

Any expressions other than simple constructors in let statements
Input/output types of trait methods (implementation site)

changelog: new lint: [`refcell_cell`]

rustbot · 2026-08-08T01:03:57Z

Thanks for the pull request, and welcome!

You should hear from one of our reviewers after this PR gets at least 2 reviews from the community.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

CommanderStorm

Community review:
Seems like a good start, but I think it needs another round in the oven given that both the perf caveats and the other lints are not fully 100% aligned.

View changes since this review

CommanderStorm · 2026-08-09T17:38:03Z

+            // Because this may be required to be `RefCell`
+            let mut app = Applicability::MaybeIncorrect;


Seems like a bit of an unclear comment. Can you clarify this comment?

Fixed:

// This can be a false positive, for example, when passed to a function // that requires `RefCell`.

It should ideally be handled, but I'm not sure whether it is feasible. I need some time to investigate.

CommanderStorm · 2026-08-09T17:41:25Z

+            let mut app = Applicability::MaybeIncorrect;
+            let sugg = {
+                let (init, _) = snippet_with_context(cx, span, stmt.span.ctxt(), "..", &mut app);
+                init.into_owned().replace("RefCell", "Cell")


this .replace("RefCell", "Cell") seems suspicious.

How about RefCell<InnerRefCell> where InnerRefCell is a struct with Copy?

Fixed. I now address HIR directly.

CommanderStorm · 2026-08-09T17:46:05Z

+                snippet(cx, init.span, "").contains("RefCell"),
+                let_stmt
+                    .ty
+                    .is_some_and(|ty| snippet(cx, ty.span, "").contains("RefCell")),


Is the blanket String .contains here safe, as in does this have false-positives? Can't we do this via matching instead as in the outer if-let?

Fixed. I now handle both the type annotation and the initialization expression directly.

CommanderStorm · 2026-08-09T18:41:48Z

@@ -1,3 +1,4 @@
+#![allow(clippy::refcell_cell)]


can this be expect? (also applies to the other instances)

The reason behind this is that this way we "GC" these lints when they don't apply.

CommanderStorm · 2026-08-09T18:44:10Z

instead of an lint, should this be a change to that lint to not lint in this case?

Since refcell_cell is a perf lint, I think it should be fired in this case. Using RefCell over Cell here can be a matter of style, and I think the choice between perf and style should be left to users.

CommanderStorm · 2026-08-09T18:45:11Z

should we not instead add an exeption to those lints to not lint?

They seem a bit conflicting...

See #17522 (comment).

CommanderStorm · 2026-08-09T18:50:58Z

+    /// ### Why is this bad?
+    /// `RefCell` avoids cloning at the cost of additional memory usage and
+    /// instructions, which isn't worth it for `Copy` types.
+    ///


there are some Known problems regarding trait bounds as noted in the tests, can we document them here?

Also, we need to note that while on avarage this is a good idea, there might be better options..

There is no runtime cost to using Cell<T>, however if one is using it to wrap larger (Copy) structs, it might be worthwhile to instead wrap individual fields in Cell<T> since each write is a full copy of the struct

https://manishearth.github.io/blog/2015/05/27/wrapper-types-in-rust-choosing-your-guarantees/

I documented it and introduced new configuration named max_cheap_copy_size to suppress the lint for large Copy types. The default value is 16, witch is the size of u/i128.

How did you come up/reason that this should be 16? (It might be right, but I'd like to know how you came up with it) 🤔

Can you add that either as a comment or into the PR description since otherwise it is not very clear.

To be honest, I chose it simply because it's the minimum size required to represent all primitive integer types. But the word size is better, since it usually fits in a cache line. And since this is a perf lint, performance should take priority over avoiding extra configuration.

rustbot added the S-waiting-on-community-reviews Status: This is awaiting for positive reviews from the community before a maintainer is assigned. label Aug 8, 2026

rustbot added needs-fcp PRs that add, remove, or rename lints and need an FCP S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Aug 8, 2026

qdot3 marked this pull request as draft August 8, 2026 01:06

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Aug 8, 2026

qdot3 marked this pull request as ready for review August 8, 2026 01:51

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Aug 8, 2026

This comment has been minimized.

Sign in to view

CommanderStorm suggested changes Aug 9, 2026

View reviewed changes

qdot3 marked this pull request as draft August 11, 2026 14:55

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Aug 11, 2026

qdot3 force-pushed the refcell_cell branch from ed24339 to 1412ccc Compare August 11, 2026 23:40

This comment has been minimized.

Sign in to view

qdot3 added 9 commits August 14, 2026 15:04

add tests

9f357db

impl logic

732e11c

improve let-stmt pattern

4b1a6a7

add tests

9803d77

write doc

68e6d3e

configure lint

71c45a2

fix *.fixed file

a8cc347

fix example

2fd2ac5

fix simple ctor pattern

f943fcd

qdot3 force-pushed the refcell_cell branch 2 times, most recently from 0246405 to 8cef563 Compare August 14, 2026 06:18

suppress the lint for large Copy types

453d1d4

qdot3 force-pushed the refcell_cell branch from 8cef563 to 453d1d4 Compare August 14, 2026 06:31

Lint &RefCell usage except in return types

4af35b8

		// Because this may be required to be `RefCell`
		let mut app = Applicability::MaybeIncorrect;

Uh oh!

Uh oh!

Conversation

qdot3 commented Aug 8, 2026

Uh oh!

rustbot commented Aug 8, 2026

Uh oh!

This comment has been minimized.

CommanderStorm left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

qdot3 Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

qdot3 Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

qdot3 Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CommanderStorm Aug 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

CommanderStorm left a comment •

edited by rustbot

Loading

qdot3 Aug 11, 2026 •

edited

Loading

qdot3 Aug 12, 2026 •

edited

Loading

qdot3 Aug 14, 2026 •

edited

Loading

CommanderStorm Aug 14, 2026 •

edited

Loading