I doubt you need a full semantic tree. Just the parts that are accessible to the local edit scope. Like if I break the code within a function, all other code in the unit should be ok. It gets trickier with broken syntax but there’s a lot of clever recovery techniques I’ve seen.
How do you propose code completions are done without it? To even produce a set of suggestions, you need to understand the parse context, the set of available symbols with appropriate types and scope resolution. AST parsers already have recovery mechanisms, and I am assuming those are all working as intended.
When I’m in function foo I may have a local closure X. When I’m editing bar I don’t need to consider X, right?
I think what you’re trying to say is “how do you pick a subset of a tree to load at any given point” / “it’s simpler to have the entire semantic tree and traverse it than trying to keep a live tree”. If that’s a correct reading, I agree, it’s a difficult problem. I don’t have any specific recommendations other than to note it’s a graph and graph databases don’t need to keep the entire graph in memory to do queries so there must be something similar you could do with code. The other part is that not all parts of the graph are equally relevant so intelligently pruning it should result in better completions. I explored this mildly as an undergrad but the topic never sufficiently interested me to continue pursuing it.
If foo is a function in this example, then yes I agree for most PLs. If foo is a class, namespace, or some other declaration context however, its contents are definitely relevant when editing a different context due to possible usage of scope operators.
