Rubberduck: Wrong "variable 'version' is not used" inspection warning

Created on 14 Jun 2018  路  4Comments  路  Source: rubberduck-vba/Rubberduck

I am getting the Variable 'version' is not used warning for the version variable on this sub:

' Credits: Maxime Port茅. Adapted from https://stackoverflow.com/a/31720382/2316433.
Public Sub PrintComponentVersions()
    Dim reference As Object
    Dim fso As Object 'Scripting.FileSystemObject
    Set fso = CreateObject("Scripting.FileSystemObject")
    ' List of references
    For Each reference In ThisWorkbook.VBProject.References
        Dim version As String
        version = fso.GetFileVersion(reference.FullPath)
        Debug.Print reference.Name & " : " & version
    Next
End Sub

The Debug.Print usage is not being considered as valid by the inspection, but in this particular case I think it's valid, since the function is supposed to write the required version values to the Immediate Window. I have another occurence of this inspection for a variable that is used to write a sub's execution elapsed time to the Immediate Window, which I also think is valid.

My suggestion would be to add a rule to count the Debug.Print variable appearances as valid usages, instead of having to mark each variable declaration with the '@Ignore VariableNotUsed annotation.

Thanks!

bug feature-inspections inspection-false-positive resolver

Most helpful comment

I just enabled logging to generate this log: RubberduckLog.txt.

The only seemingly related lines look like this:

2018-06-14 11:43:57.9906;WARN-2.2.6737.8365;Rubberduck.Parsing.Symbols.IdentifierReferenceResolver;Debug.Print (custom declaration) has not been loaded, skipping resolving Debug.Print call.;

By the way:
Version 2.2.6737.8365
OS: Microsoft Windows NT 10.0.17134.0, x64
Host Product: Microsoft Office 2016 x86
Host Version: 16.0.9330.2087
Host Executable: EXCEL.EXE

All 4 comments

I've been having resolver problems lately (only on 1/2 machines though) - if the resolver isn't working then inspections are indeed going to be firing a ton of false positives (they need to assume declarations and their references were resolved correctly).

Do you have logging enabled? If so, would you happen to have resolver errors logged, something like "library VBA couldn't be loaded", then "library Office couldn't be loaded", and "library Excel couldn't be loaded"? If logging is off, you can still notice something is off: the initial parse "loading references" step will take much longer than normal (the half-ton of exceptions slow it down to a crawl).

Or is it just Debug.Print argument expressions that don't get resolved? That does ring a bell...

I just enabled logging to generate this log: RubberduckLog.txt.

The only seemingly related lines look like this:

2018-06-14 11:43:57.9906;WARN-2.2.6737.8365;Rubberduck.Parsing.Symbols.IdentifierReferenceResolver;Debug.Print (custom declaration) has not been loaded, skipping resolving Debug.Print call.;

By the way:
Version 2.2.6737.8365
OS: Microsoft Windows NT 10.0.17134.0, x64
Host Product: Microsoft Office 2016 x86
Host Version: 16.0.9330.2087
Host Executable: EXCEL.EXE

This appears to be fixed as of #4181.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ishita799 picture ishita799  路  28Comments

JonTheNiceGuy picture JonTheNiceGuy  路  37Comments

brab picture brab  路  49Comments

bclothier picture bclothier  路  33Comments

BACEjackson picture BACEjackson  路  23Comments