327: Beginnings of type inference r=flodiebold a=flodiebold
I was a bit bored, so I thought I'd try to start implementing the type system and see how far I come 😉 This is obviously still extremely WIP, only very basic stuff working, but I thought I'd post this now to get some feedback as to whether this approach makes sense at all.
There's no user-visible effect yet, but the type inference has tests similar to the ones for the parser. My next step will probably be to implement struct types, after which this could probably be used to complete fields.
I realize this may all get thrown away when/if the compiler query system gets usable, but I feel like there are lots of IDE features that could be implemented with somewhat working type inference in the meantime 😄
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
302: WIP: Support tracing lsp requests. r=DJMcNab a=DJMcNab
EDIT: We need to work out a better way to handle settings before this can be merged. Help wanted
TODO: Debug why decorations are sent even when highlightingOn is disabled
This makes the log volume so high its impossible to work with anyway.
(Continuation of #84 [#99 only disabled using it, not making sure we don't send it]).
These logs can be used in https://microsoft.github.io/language-server-protocol/inspector/
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
322: Fix analyzer extension fail when there are enabled any VIM extension r=matklad a=max-frai
`type` command is allowed only once to be registered and it was built specially for vim mode.
So if user has vim extension enabled, rust-analyzer initialization failes on trying to register own `type` handler.
Unfortunatelly, there are no nice ways to check if command is already registered so the way is to wrap everything with try/catch and notify user about conflict.
Co-authored-by: frai <me@maxfrai.com>
321: More useful logging r=matklad a=matklad
Try not to log *huge* messages, to make logging more useful.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
This improving this code is not a good use of people-time, and this
might be the most performant approach nonwithstanding
an api for this use case being added to walkdir
