v2.1.1

Follows XLIDE 6.2.0, which fixes the issue this port reported upstream (xlide_vscode#68). The vendored data is byte-identical to 6.1.2, so only the manifest's version moves; the analyzer change below is the whole release.

A module's own procedures shadow the host's globals

A module VARIABLE named rows already resolved from its declaration, but a procedure of the same name did not:

Public Property Get rows() As Widget
End Property

Public Function Where(ByVal p As Variant) As Widget
End Function

Public Function Use(ByVal p As Variant) As Widget
    Set Use = rows.Where(p)      ' rows fell through to Excel's global Rows
End Function

The names that collide are the ones every workbook uses: rows, columns, cells, selection, names, sheets, application. A Function or Property Get now yields its return type; a Sub, or a Property with only Let/Set, yields nothing readable but still shadows the global rather than letting the host answer for it.

What changes for you

This port never emitted the false positive upstream had, because it resolved such a receiver to nothing at all rather than to the wrong type. The fix replaces that silence with a correct binding, so a receiver that used to go unchecked is now checked: with project context, a genuinely absent member on one of these names reports member-not-found where it previously passed. Analyzed standalone, without project context, behaviour is unchanged.

Verification

Differential against the upstream 6.2.0 analyzer: 418 of 418 oracle cases identical in both directions, and identical on a real workbook's modules. 16 real workbooks stay silent. 3,039 tests green; ruff and mypy clean; CI green across Python 3.10 to 3.13 and the language matrix on Linux and Windows.

Upstream's other 6.2.0 work is the seven refactorings, which are editor code actions and out of scope for this port.