> Moved listeners to Rubberduck.Parsing.Listeners. This is work in process; most listeners will no longer be needed after the symbol table is completed.
I think we can expect major performance boosts if that's done right
1.21 walks the parse trees WAY to often, and much more than actually needed.
even the code explorer's TreeViewListener is moot.
shortly put, DeclarationSymbolsListener traverses all parse trees once, and VBProjectParseResult then contains all declared identifiers, their type, location, scope, visibility, etc. - there's no need to re-traverse the parse trees to get the methods, and once more to get the declarations, and once more to get the assignments, and once more to get the variable references... we'll need 1 pass to get all identifiers, and another pass to get all usages of every single identifier.
actually the latter pass only needs to be done when it's needed to do so; there's no need to get all usages just to render a treeview, for example.
I like where this is going.
...except merging that branch is becoming VERY scary now.
> Let's add a "Find all references" search command in the Code Explorer context menu, and in the code pane's context menu, so that it's possible to find all references of an identifier just by right-clicking it. Ideally the context menu button should be disabled if the cursor isn't located on an identiifer that was picked up by the DeclarationSymbolsListener.
> Let's add a button to the to the code explorer context menu, so that when a class module is right-clicked, it's possible to locate all implementations in all opened projects.
> @christophocles as someone new to the code base, do you feel it would help if we created an [Easy-Fix] label and tagged the issues we feel would be easy for someone new to handle?
supporting both VBA & VB6 is a challenge though, especially with source control - only VBA files need to be extracted. And unit testing in VB6 might not be possible.
I have a simple List<string> and I'd like it to be displayed in a DataGridView column.
If the list would contain more complex objects, simply would establish the list as the value of its DataSource property.
But when doing this:
myDataGridView.DataSource = myStringList;
I get a column called ...
I think I'm progressing. Parsing needs to make 2 passes (excluding the actual parsing of the text file). 1st pass: collect all declarations (including modules/class modules, fields, enums, types, functions, procedures, properties, etc.). 2nd pass: locate all AmbiguousIdentifierContext instances in the parse tree, and map them to a declaration whenever possible.
I've already implemented the listener for pass 1. Working on the listener for pass 2.
I'll literally be .Adding IdentifierReferences to Declarations - so if all goes well, finding unassigned variables will look something like _declarations.Where(d => d.DeclarationType == DeclarationType.Variable && !d.References.Any(r => r.IsAssignment))
the listener has to do the dirty work of figuring out the context around an identifier
private bool IsGlobalField(Declaration declaration)
{
// a field isn't a field if it's not a variable or a constant.
if (declaration.DeclarationType != DeclarationType.Variable ||
declaration.DeclarationType != DeclarationType.Constant)
{
return false;
}
// a field is only global if it's declared as Public or Global in a standard module.
var moduleMatches = _declarations[declaration.ComponentName].ToList();
private bool IsGlobalProcedure(Declaration declaration)
{
// a procedure is global if it's a Sub or Function.
// since we have no visibility on module attributes,
// we must assume a class member can be called from a default instance.
if (declaration.DeclarationType != DeclarationType.Procedure ||
declaration.DeclarationType != DeclarationType.Function)
{
return false;
}
// Friend members are only visible within the same project.
private void EnterIdentifier(RuleContext context, Selection selection)
{
var name = context.GetText();
// there should only be one match here.. in theory...
var matches = _declarations[name].Where(IsInScope);
// ...but let's not make that assumption:
foreach (var declaration in matches)
{
var isAssignment = IsAssignmentContext(context);
var reference = new IdentifierReference(_projectName, _componentName, name, selection, isAssignment);
I'm not going to be home until much later tonight. I think I have all I need now, just need to wire it up and then IdentifierUsageInspector can be removed, and the inspections using it can start using the _declarations directly.
I have a simple List<string> and I'd like it to be displayed in a DataGridView column.
If the list would contain more complex objects, simply would establish the list as the value of its DataSource property.
But when doing this:
myDataGridView.DataSource = myStringList;
I get a column called ...
VBA Rubberducking
VBA Rubberducking