9519: Explicitly name all spawned threads r=weirdsmiley a=weirdsmiley
Fixes: [#9385](https://github.com/rust-analyzer/rust-analyzer/issues/9385)
The thread name is shown in debugger as well as panic messages and this
patch makes it easier to follow a thread instead of looking through
full backtrace, by naming all spawned threads according to their
functioning.
Co-authored-by: Manas <manas18244@iiitd.ac.in>
The thread name is shown in debugger as well as panic messages and this
patch makes it easier to follow a thread instead of looking through
full backtrace, by naming all spawned threads according to their
functioning.
9500: internal: Only inline closure, literal and local arguments when used once r=Veykril a=Veykril
See https://github.com/rust-analyzer/rust-analyzer/pull/9474#discussion_r663881507 for reasoning.
This still inlines single use closures and literals as naming these is usually not as useful. Prime examples being the Option/Result consuming functions like `map_or` etc.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9496: fix: make the logs line buffered r=lnicola a=mahdi-frms
fixes#9432
Not quite sure if that's what you want, but storing the log message in buffers eliminated the tiny write syscalls for me.
I just changed the Logger struct.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
9499: fix: Fix cycle in visibility computation with modules from the same block r=jonas-schievink a=jonas-schievink
fixes https://github.com/rust-analyzer/rust-analyzer/issues/9481
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9497: Wrap inlined closures in parens when inlined in an expression in `inline_call` r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9478: show imported trait on autocompletion of associated items r=matklad a=mahdi-frms
Fixes: #7456
The thing is however, due to the trait being already imported, the path to the trait is just the name of the trait itself.
I also updated the test concerning the labels.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
Note that, while we don't currently have a fuzzy-matching score, it
makes sense to special-case postfix templates -- it's very annoying when
`.not()` gets sorted before `.not`. We might want to move this infra to
fuzzy matching, once we have that!
Before this PR, SourceChange used a bool and CompletionItem used an enum
to signify if edit is a snippet. It makes sense to use the same pattern
in both cases. `bool` feels simpler, as there's only one consumer of
this API, and all producers are encapsulated anyway (we check the
capability at the production site).
