Introduce inspections for indexed default member accesses
There are three versions: IndexedDefaultMemberAccessInspection for ordinary default member accesses, IndexedRecursiveDefaultMemberAccessInspection for those requiring a recursive default member resolution and IndexedUnboundDefaultMemberAccessInspection for those on Object and Variant variables.
Add inspections for implicit default member accesses
These do not cover procedure coercions, which are covered separately. In particular, we have ImplicitDefaultMemberAccessInspection for ordinary not parameterized ones, ImplicitRecursiveDefaultMemberAccessInspection for not parameterized ones that require a resolution via a chain of default members and ImplicitUnboundDefaultMemberAccessInspection for unbound not paramterized ones.
> I've modified the logger message per the suggestion above in addition to throwing an `OperationCanceledException` using the `RefactorFailure_BaseMessage` resource.
I wrote the Suspend-Parser code for `RenameRefactoring` based on what I found in the `ExtractInterfaceRefactoring`. The above comments would apply to the `ExtractInterfaceRefactoring` as well. So, I've modified its Suspend-Parser code in the same manner.
@Duga @M.Doerner looking inside the Exceptions folder, there doesn't seem to be anything for suspension failure. Would using RefactoringAbortedException be appropriate? Not sure if a failure to suspend should cause an operation cancellation.
I also wonder why the generic exception classes doesn't use the base message resource as its default placeholder.
@this I looked at using RefactoringAbortedException but was hesitant to modify the exception class (I wanted a ctor that took a message). I'll go back and modify the RefactoringAbortedException class and re-sync...unless you would rather I leave it as-is for now.
AFAIR, the RefactoringAbortedException is meant to facilitate voluntary aborting an exception, i.e. when the user chooses to cancel on any confirmation. Because of that it is never reported.
The reason to use an exception for flow control here it that it is otherwise very complicated to abort from inside the UI part.
If you want an exception for suspension failure, please add another exception.
IIRC, the refactoring commands only report on subclasses of RefactoringException and rethriw everything else except the RefactoringAbortedExceprion.
> So far, we only have one refactoring command in the CE. This is why no `CodeExplorerRefactoringCommandBase` has been introduced so far, in analogy to the other ones for refactorings. Since we will soon have another refactoring command in the CE, we should add that base class.
Unfortunately, this will not be able th inherit from `RefactoringCommandBase` because it already has to inherit from `CideExplorerCommandBase`.
> One possible option is to make RefactoringCommandBase a protected backing field and delegate work to it. If the field needs to be extended, we might consider creating a nested type deriving from `RefactoringCommandBase‘ and use it for the backing field and hopefully minimize code duplication this way.
@Vogel612 whoooshthe sound that one made while going over my head
@IvenBach Wow! FUD - the police's job is done. OMG! OMG! OMG!!! SOMETHING BAD IS HAPPENING!!!! Where is it? We can't tell you What's the situation? We won't tell you Why won't you tell us anything? Just sit there and be terrified "the government" will protect you.
Um, no. A byte is 8 bits. That's 2^8 = 256 possible values. A byte by default is unsigned, unlike all other integers which are signed by default. Were it signed, it would be -128 to 127.
Makes me wonder why the little inconsistency of not considering byte signed. We get uint, ulong, but sbyte because of that.
The reason a type "byte", without any other adjective, is often unsigned while a type "int", without any other adjective, is often signed, is that unsigned 8-bit values are often more practical (and thus widely used) than signed bytes, but signed integers of larger types are often more practical ...
(technically that's not really a C# question, since that's a convention that existed before the C# but the answer linked does include historical info)
But I have the problem with getting it. It seems to be the only way for getting the TODO-List is clicking on Pending/Refresh.
Pending/Refresh creates not only the TODO-List but also the code-database.
So there is my problem: As rubberduck uses excessive amounds of RAM when creating the code-database ms-access usually crashes soon after clicking "Pending/Refresh" because of "Out of memory".
As I can see it there are several solutions to my problem:
@M.Doerner Right. I was thinking more about managing the future changes that may be necessary to the RefactorCommandBase. If the CodeExplorerRefactorCommandBase does not use the RefactorCommandBase, it would miss out on the future changes. It might be unnecessarily complicating things, though.
@Hosch250 Yep! All those tidbits contributes to the hockey stick.
@Duga is a annotation-only parsing really practical?
The VBE API, IIRC, tells us which proc they are typing in (or we can use the API to get it, or something).
I forgot how exactly that works.
Anyway, we grab the text for just that proc from the VBE and get a parse using just that, and instead of asking for the root node, we go up to the next level node.
And then we get the updated parse node and replace it in the existing tree.
And then we remove that node and its children from the declarations and resolve declarations on that node.
And then the same for the references.
Remove any references in that location, and re-calculate references just for that block.
There's one piece that could be a little bit problematic.
Yeah that would work. I'm more concerned about references, though. Right now, they are module to module references and I think we only resolve them at module level.
Yeah. Changing the signature would be other case. That means we need to detect changes made to the certain elements and mark it as module change rather than procedure change.
IMO, procedure changes should be limited to only inside the body
which is the most typical case (I hope)
Avalon or no avalon, we do need it to be more granular.
The generated type library will be missing some features, and you won't get any custom code analyzers running, but that should not prevent you from developing on RD.
I wish I had a easy and quick solution to the build but I don't. :(
You can run MongoDB 3 with in memory storageEngine: mongod --dbpath path_to_folder --storageEngine=inMemoryExperiment — Gerardo HernandezJul 13 '15 at 16:57
> If we don't parse the code, we don't know what todo markers are in it... also, the last couple of indenter bugs still present, will be *much* easier to address when the indenter uses the parse trees, as is the plan.
So basically, the proposal/request here is to put 99% of our work behind a *kill switch* to essentially cripple the add-in by disabling all the navigation tooling, code inspections, refactorings, ...everything.
I very much understand that memory consumption is an issue (c.f.
> Also -- in case you missed it, [github.com/rubberduck-vba/Rubberduck/issues/5176](there is a open case) to address the memory consumption. You also are more than welcome to help and contribute a PR to address the memory & performance issues.
> Also -- in case you missed it, there is a open case ( #5176 ) to address the memory consumption. You also are more than welcome to help and contribute a PR to address the memory & performance issues.
Just in a weird place of having a new job, not being able to tell my coworkers for another week (because I'm finishing a big project at work and don't want to give notice just yet), and being crazy busy with said project and a couple others that got thrown on me quick.
Everything is done, my boss knows I'm on my way out, so they aren't putting any more on, because they know this one has to go right, because we deploy Thursday, I leave Friday, and start my next job Monday, and the project is pretty high impact.
That's why they tossed a couple projects on me quick, though, just to get them done finally.
@FreeMan IDK if that ever happened in VBA projects but in Win32 API, it has been the case where there was a value that used to do something but now is moot, so they make it 0x0.
I'm pretty sure that in Windows 9x days there used to be a difference between the WS_TILED and WS_OVERLAPPED but since then they said, "that's dumb" and made it the same
but they can't drop the constant because there might be some application out there compiled against the old header file blah blah blah
Anyway, so that's a problem w/ Win32 API. Is it with VBA projects? I can't imagine it being so.
VBA Rubberducking
VBA Rubberducking