@MartinGC94 I had a lot of doubts about this approach. On the one hand, it is very tempting to have it, users get useful features when editing scripts. On the other hand, this approach has many problems. This code is difficult to understand, has limitations in its capabilities, and most importantly, it is almost impossible to cover it with exhaustive tests. I expected users to report problems, but it turned out to be even worse - the first message was about a crash.

So I think we should revert these two PRs and use a different approach to realize these opportunities.
I think it is more correct to use the already used approach based on "safe evaluating".

@iSazonov I don't understand what you mean about the old code being based on "safe evaluating".
The old code was also finding and analyzing relevant asts, the only difference is that I use a custom visitor while the old approach used an AstSearcher. However, it's not like the custom visitor is fundamentally less safe than the old approach. I managed to make a similar infinite loop bug when updating the type inference for$_ in switch statements:#21221 and here I used the old loop approach.
I'm also using a very similar approach in the variable completion code and that has been running fine since June 2023:#19595

I think it would be a mistake to completely abandon a perfectly fine way to handle type inference for variables just because of one mistake that happened to cause a crash.

@MartinGC94 It's not just a single mistake or that this approach has been used before. The problem is how to prove the correctness of this code - although we added a lot of tests, we did not see this problem.
Moreover, using this approach in the past does not guarantee that it is the best one.

I have no intention of forcing you to rewrite all the code in this feature, I'm just expressing my opinion and I feel that the code is becoming more complex, although it was originally conceived as a simplified workaround that works on older computers twenty years ago. Now we have more powerful computers (and besides, we prefer the IDE to the command line). That's why I keep coming back to the idea that maybe it's time to do these calculations in a more advanced way.

@iSazonov What do you mean with safe eval and more powerful computers? We can't just execute all the previous statements to get the actual value because those statements could have side effects. A quick example would be:$VM = New-VM; $VM.<Tab>. where tab completing obviously shouldn't result in a new VM being created every time.
Static analysis that determines what command set a value, and then checking the possible output from that command seems like the only reasonable way to do this, but if you can think of a better way then feel free to share it.

@MartinGC94 Here are my 2 cents. I'm a heavy terminal user, and the enhancements you've delivered have significantly improved my experience. I understand Ilya's point about proceeding with care, but from my perspective, the advantages are well worth it—even if minor bugs pop up along the way.

/azp run

📣 Hey@MartinGC94, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗https://aka.ms/PSRepoFeedback

Microsoft Forms