Skip to content
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

Renames and indent-changes in big projects #4200

Open
Gener4tor opened this issue Jul 17, 2018 · 1 comment
Open

Renames and indent-changes in big projects #4200

Gener4tor opened this issue Jul 17, 2018 · 1 comment

Comments

@Gener4tor
Copy link

Gener4tor commented Jul 17, 2018

When I try to rename a function which is used in a lot of forms or I use the indent-feature with "current project" access runs into memory problems and the rename (and the indent) is only half done.

Version 2.2.0.3468
OS: Microsoft Windows NT 10.0.16299.0, x64
Host Product: Microsoft Office 2016 x86
Host Version: 16.0.4711.1000
Host Executable: MSACCESS.EXE

@retailcoder retailcoder changed the title Renames and intend-changes in big projects Renames and indent-changes in big projects Jul 17, 2018
@retailcoder
Copy link
Member

Thanks for reporting. How large is the project? Is logging enabled, do you have any interesting log entries?

The indenter and the rename refactorings are two completely unrelated components, probably best to address them separately.

The indenter iterates each module sequentially and temporarily stores (and returns) an array of strings containing the entire module's raw code (no parsing involved). How large a module are we looking at? Note that VBA will refuse to compile anything exceeding 10K lines of code.

Refactor/rename iterates all references to the selected identifier/declaration (this requires full parsing and resolving of all modules), and proceeds to replace the corresponding tokens in each module's lexer token stream, using a TokenStreamRewriter that creates a "rewriter program", with each token replacement as a single step. If the operation completes for all modules, each rewriter program is then executed for each individual module (again, sequentially), and each module's content is fully replaced in a single operation, which preserves as much of the VBE's undo stack as possible (Ctrl+Z once clears the module, Ctrl+Z twice reverts to pre-rewrite state).

Rubberduck is RAM-heavy (see #3347), which is quite possibly more of a problem in a more limited 32-bit host.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants