Repository navigation
Add a lint for attempting to mutate a const item #345
Description
Proposal
Add a new lint CONST_ITEM_MUTATION. Given an item const FOO: SomeType = .., this lint fires on:
- Attempting to write directly to a field (
FOO.field = some_val) or
array entry (FOO.array_field[0] = val) - Taking a mutable reference to the
constitem (&mut FOO), including
through an autoderefFOO.some_mut_self_method()
The lint message explains that since each use of a constant creates a
new temporary, the original const item will not be modified.
The need for such a lint was brought up in rust-lang/rust#74053, rust-lang/rust#55721, and rust-lang/rust-clippy#829
While this could be a clippy lint, I believe that this is important enough to go in the compiler. Without this lint, users may write useless code which is silent accepted (e.g. FOO[0] = my_val or MY_CONST_VEC.push(val)). Such code may come about as a result of unrelated refactoring (e.g. changing a static to a const, and changing a method to use &mut self instead of interior mutability).
Mentors or Reviewers
I've implemented this lint in rust-lang/rust#75573
cc @oli-obk
Process
The main points of the Major Change Process is as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
Activity
rustbot commentedon Aug 17, 2020
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
flip1995 commentedon Aug 17, 2020
FWIW there was already an issue opened in Clippy asking to uplift a lint that does similar things (
temporary_assignment)The issue: rust-lang/rust-clippy#4497
petrochenkov commentedon Aug 17, 2020
@rustbot second
shepmaster commentedon Aug 18, 2020
See also Why are const atomic variables not updated, but static atomic variables are?
nikomatsakis commentedon Aug 20, 2020
Technically speaking lints require approval by lang team, particularly if they are warn-by-default -- but I think this is a good idea. Can you nominate the PR once for T-lang it is ready, @Aaron1011 ?
cc @rust-lang/lang
Aaron1011 commentedon Aug 20, 2020
@nikomatsakis This is my first time filing an MCP - should I wait for the final comment period to end before nominating it?
scottmcm commentedon Aug 22, 2020
I agree that this sounds like a good idea.
It feels like we need to have a process for this that doesn't need FCPs on both a compiler MCP and a lang something.
nikomatsakis commentedon Aug 27, 2020
@Aaron1011 sorry what I meant was, go ahead and write the PR, just nominate it once it is ready
nikomatsakis commentedon Aug 27, 2020
i.e., let's consider the MCP approved