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

Questionable behavior in "Code inspections" #6195

Open
alterreg0 opened this issue Jan 26, 2024 · 1 comment
Open

Questionable behavior in "Code inspections" #6195

alterreg0 opened this issue Jan 26, 2024 · 1 comment
Labels
bug Identifies work items for known bugs

Comments

@alterreg0
Copy link

alterreg0 commented Jan 26, 2024

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

@alterreg0 alterreg0 added the bug Identifies work items for known bugs label Jan 26, 2024
@retailcoder
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Identifies work items for known bugs
Projects
None yet
Development

No branches or pull requests

2 participants