rubberduck-vba/Rubberduck

Questionable behavior in "Code inspections"

Opened this issue · 1 comments

Rubberduck version information
Version 2.5.9.6316
OS: Microsoft Windows NT 10.0.22621.0, x64
Host Product: Microsoft Office x64
Host Version: 16.0.17126.20132
Host Executable: EXCEL.EXE

Description

Hello.
Firstly, thanks for the great tool - improved vba project explorer is what I had been thinking about for years - but never had enough time to develop)

I was using mostly project explorer only, but few days ago installed new version - and decided to explore other functionality.
During tesing "Code inspections" was detected some behavior, which seems questionable.
Found 2 typical situations:
(1) assigning to instance of class X value, which declared type is interface, implemented by X
(2) passing variable to method, which returns result in passed variable

Screenshots attached below
As a user - I have absolutely no problem with described behavior - so informing just in case this could be useful for developers.
Regards

(1)
image

image

same:
image

(2)
image

image

image

Thanks for the report, I hope you get to discover the rest of the features! 🥰

The MSO CommandBar issue is a weird one, it seems we already have all the necessary information to correctly identify the implemented interfaces there; surely something must be weird with the way they're made that somehow confuses our resolver into failing to identify the interface, because it's the same code for all COM libraries!

As for ByRef returns, that's a known and deliberate limitation of the inspection, although we could certainly make an exception for library functions since the motivation is about the performance penalty incurred by tracking whether an argument passed to a ByRef parameter is actually assigned in the called procedure or not (which would be a rabbit hole); I think it's reasonable to treat out parameters as an assignment to the argument expression, assuming that expression resolves to a known identifier.