False positives

Thank you very much for sharing the analyzer. I’m in process of trying this out with Rubberduck-VBA. This project involves quite a lot of manual management due to deep COM interop and a large part of architecture relies on IDisposable interface to explicitly control the lifetime of wrapped COM objects.

I’ve found few false positives. I do not know if those are something we can fix or enhance but I thought I’d at least point them out.

With IDISP001 rule we are flagged here:

var component = _state.ProjectsProvider.Component(target.QualifiedName.QualifiedModuleName);

The component here is a IDisposable object which we obtain via the _projectsProvider.Component. The intention with the ProjectsRepository is that the class is responsible for the lifetime of its objects, so thus we shouldn’t dispose anything we get out of the ProjectsRepository.

We have a similar situation here:

var subclass = Subclasses.Subclass(hwnd);

As above, Subclass returns a IDisposable object from a cached collection.

With IDSIP007 rule we also get flagged here:

using (var module = component.CodeModule)
{
  ...
}

In this case, CodeModule is similarly a IDisposable object. However, the CodeModule property reads:

public ICodeModule CodeModule => new CodeModule(IsWrappingNullReference ? null : Target.CodeModule);

Thus, using is actually appropriate in this case since we get a new object and thus are responsible for disposing it.

With IDISP003, we have a false positive for this code:

        void ComTypes.ITypeInfo.GetRefTypeInfo(int hRef, out ComTypes.ITypeInfo ppTI)
            => ppTI = GetSafeRefTypeInfo(hRef);

This flags the ppTI as needing to be disposed. What I don’t get, though is that the variable has type of ITypeInfo, which does not implement IDisposable. If I try to apply the quickfix, I get the following code:

        void ComTypes.ITypeInfo.GetRefTypeInfo(int hRef, out ComTypes.ITypeInfo ppTI)
        {
            (ppTI as IDisposable)?.Dispose();
            return ppTI = GetSafeRefTypeInfo(hRef);
        }

Which does not look at all appropriate to me.

Another example is here for this section of code:

                            IHostApplication result;
                            if (hostAppControl.IsWrappingNullReference)
                            {
                                result = null;
                            }
                            else
                            {
                                switch (hostAppControl.Caption)
                                {
                                    case "Microsoft Excel":
                                        result = new ExcelApp();
                                        break;
                                    ...<several other cases>....
                                    default:
                                        result = null;
                                        break;
                                }
                            }

                            _host = result;
                            return result;

For each case, the result is flagged in spite of the fact that it’s a local variable and thus cannot be been previously assigned.

I have not gone though all other issues and will update as I proceed.

I know we can add suppress message but I want to avoid suppressing it everything. We got about 1500 warnings and we’re going to have to assess them one by one because of some false positives.

[JohanLarsson]

using (var module = component.CodeModule)
{
}

Reason IDISP007 nags here is again heuristics, it assumes that a property does not return a created disposable that the ~caller owns. Needs annotations #126

A property returning a created reference type is not awesome design if you ask me.

[JohanLarsson]

Closing this, open new issues if I forgot things.