-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Metadata
Metadata
Assignees
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
bblum commentedon Aug 2, 2012
+1. i'm all for compiler warnings that make folks tighten down their code.
bstrie commentedon Aug 7, 2012
Would it work similarly to the unused variable detection, where it warns unless you stick an underscore on the front of the identifier?
zmanji commentedon Aug 8, 2012
I would like to work on this issue but I don't know where to start. Can anyone provide me with some tips?
nikomatsakis commentedon Aug 8, 2012
The
liveness
pass already pretty much computes the information you need. It can be found insrc/rustc/middle/liveness.rs
, but you probably want to come on IRC and ask me (nmatsakis) questions about it.nikomatsakis commentedon Aug 8, 2012
I'm not sure how familiar you are with a traditional liveness analysis, but the basic idea is that it tracks when variables may be used again (in which case they are live). Ours is a bit different in that it also tracks when variables may be reassigned in the future. Therefore, it should be possible to check, at the point where a variable is declared, whether it will ever be reassigned.
The easiest thing would be to issue a warning for mutable variables which have initializers but are never reassigned (such as the example given in this bug). Such a warning would be issued in check_local(). There is currently a check that says "if there is an initializer and the variable is immutable, ensure it is never assigned again". You could repurpose this to something like "if there is an initializer, and the variable is never reassigned again, warn if it is not immutable" (but of course it should still report the error it does today)
You might conceivably also try to issue warnings for variables that are assigned only once in the flow of execution:
as such variables also do not require a mut label. But this is trickier, I'm not sure if we have enough information available to distinguish that case from one like;
That is, each assignment can determine whether there are ever any later assignments and whether the variable is ever used later. But here it seems like we would also need to know whether there have been any prior assignments. So I'd say just warn if there is an initializer and ignore this second case.
nikomatsakis commentedon Aug 8, 2012
Note: Be sure to add a "compile-fail" test case as described here: https://github.com/mozilla/rust/wiki/Note-testsuite
This one is a bit tricky as you'll be detecting a warning, and the test suite likes for such tests to fail, so you'll probably have to add a secondary error. You can check out the test
src/test/liveness-unused.rs
as an example.ttaubert commentedon Dec 16, 2012
It's unfortunately not as easy as just adding another check to check_local(). Variables might need to be mutable not only for re-assignment:
These both result in
error: illegal borrow: creating mutable alias to immutable local variable
.huonw commentedon Dec 16, 2012
I have little idea of the infrastructure (I had a look at middle/liveness.rs, which didn't help me much), but how difficult would it be to add an
used_mutably_count
to the analysis that counts the maximum number of times a variable could possibly be assigned or used in a context that requiresmut
(accounting for loops)?e.g.
Then if
used_mutably_count(var) == Known(1)
, rustc can warn thatvar
should be immutable (or not, ifvar
is already immutable).It could be computed with rules like
where
umc(var, ast)
counts the maximum possibly assignments & mutable-uses ofvar
inast
, the operations are such that the result isUnknown
if any of the inputs areUnknown
andUnknown > Known(k)
for allk
.(I guess the count could even be compressed to
UsedNever
,UsedOnce
andUsedMany
.)graydon commentedon Mar 20, 2013
non-critical for 0.6, de-milestoning
auto merge of #5966 : alexcrichton/rust/issue-3083, r=graydon
Merge pull request rust-lang#3083 from scampi/itemized_blocks
Auto merge of rust-lang#3083 - saethlin:gc-history, r=oli-obk
Disable removal of storage markers (rust-lang#3083)