Mostly by being more flexible in its inputs and outputs than an LSP. An LSP is generally trying to perform deep static analysis on your code to provide suggestions. The upside is extremely accurate suggestions, with a pretty much 0 false positive rate (I.e. it never suggests anything uncompilable), the down side is that they tend to be much picker about their inputs.
If the code is currently in an un-parsable state, and a valid AST can’t be produced, then the LSP is forced to work with whatever parsed version of the code it was last able to build a valid AST for. Making the autocomplete results, incomplete.
VSCode on the other hand is basically performing tokenisation and fuzzy search on those tokens. It doesn’t really care about the validity of the code, that means more false positive suggestions (I.e. suggesting stuff that can’t compile), but very robust handling of un-compileable code. That plus prioritising LSP suggests over fuzzy suggestions, results in VScode providing a very nice graceful fallback for LSP failures, that people probably use more often than they expect.
If the code is currently in an un-parsable state, and a valid AST can’t be produced, then the LSP is forced to work with whatever parsed version of the code it was last able to build a valid AST for. Making the autocomplete results, incomplete.
VSCode on the other hand is basically performing tokenisation and fuzzy search on those tokens. It doesn’t really care about the validity of the code, that means more false positive suggestions (I.e. suggesting stuff that can’t compile), but very robust handling of un-compileable code. That plus prioritising LSP suggests over fuzzy suggestions, results in VScode providing a very nice graceful fallback for LSP failures, that people probably use more often than they expect.