Got a huge chunk of Rubberduck.Parsing in now; deleted the "quick-parse" parser but kept the TextReader token stream provider. Next step is to orchestrate the real RDE quick-parse, so that'll be a preprocessor pass, then a SLL-to-LL fallback parse off of what I'm hoping to be a very small parse tree with just enough to figure out the module structure.
...and then a syntactic pass with the full grammar, if there hasn't been a keypress yet
that's when we'll get the syntax error and parse tree inspection squiggles
...and if the editor is still idling then we update the out-of-process metadata
(the declarations and their references), and then the other inspections get their updated results into the editor as new squiggles
maybe it's faster to skip the first pass, I wonder
not for worst-case scenarios full of ! bang operators
Inspections would only run project-wide if you asked for it
duh the first pass is for block completion, so yeah, a small parse tree that doesn't traverse procedure bodies
@FreeMan lol yeah, mostly it's just copying files and adjusting namespaces, but I'm bringing the in the pieces one chunk at a time, making sure I know what everything is for and adjusting to the v3 paradigm - for example there's a new RubberduckEditor member in the CodeKind enum, and the parsing error strategies are slightly different.
Background
I am trying to recreate the functionality of HYPERLINK() on my own terms, as a custom UDF called Hyper_Link(). My ultimate goal is to have Hyper_Link() embed a URL that is longer than 255 characters, which is currently impossible with HYPERLINK().
I currently have a working prototype,...
Just one comment regarding the declaration model, we should really stop having strong references to the contexts in there. The way it is right now any stray declaration can hold the entire module parse tree in memory. I think this is part of our memory problem.
I think the minimal solution would be to use weak references. However, a selection and a qualified module name should also be enough to allow to retrieve the context if needed.
I think there are a few inspections that use the context on a declaration or reference to determine whether there is a problem. We will have to see how to handle them in another way or give them another way to get access to the context.
I am still a bit unsure about how to properly handle the relation between declarations and their selection.
IIRC it depends what the declaration is; most of the time the selection is that of the identifier name, but I think there might be a few exceptions to that
Maybe, we could do something in the same spirit as red green trees and only determine the selection on demand. This would remove the need to update the selection whenever something changes in the module. On the other hand, identifying when a declaration is no longer valid would become tricky.
That sounds useful. We'll, I guess we should first try to make it work with the new editor and then think about optimizing the parsing and updating.
My issue was more with the scenario that the user opens an existing module. The tricky part would be to associate the already existing declarations and references with the contexts.
Well, or when we try to navigate to a declaration in a module that is not open.
I still plan to do some research on how other projects handle the connection between semantic objects, parse trees and selections.
Specifically, I wanted to look at rust analyzer.
However, I first have to find some time to actually do it.
VBA Rubberducking
VBA Rubberducking