Rubberduck Rubberduck version: Version 2.1.2.2825
If I make some edits and then do a refactor rename, all of the edits I made revert to the original text. The rename succeeds and is not reverted on the next refactor.rename.
Thank you for reporting this. This is most likely caused by a caching issue that makes the parsing engine think that it does not have to reparse the module before renaming.
A fix for the most probable cause is included in PR #3735, which has not been merged so far.
Note that making some edits and then using any Rubberduck code-rewriting feature, will produce this result.
However:
IOW this is lower-level than refactor/rename; it's the parser state cache and module rewriters that need to get involved.
In simpler terms - code-rewriting features currently assume that the parser state is up-to-date, instead of requesting a reparse before proceeding.
We could make quickfixes and refactorings' base classes request a reparse, however that reparse should be blocking/synchronous, so as to actively prevent any further code changes during the reparse.
@MDoerner how did #3735 address this?
The commands' CanExecute implementations need to get a ContentHash diff for the current/active module from the parser state, however it would be rather inefficient to hash a module's content once for every single RD command that needs to check whether it should be enabled or not... and caching the content hash means we need to somehow invalidate that cache at some point... I don't see a definitive fix for this, at least until the code panes fire some Changed event.
The RubberduckParserState has a method IsNewOrModified that can be used to check whether the content of a module has been changed. This had a caching bug that I fixed in #3735.
Most helpful comment
The
RubberduckParserStatehas a methodIsNewOrModifiedthat can be used to check whether the content of a module has been changed. This had a caching bug that I fixed in #3735.