3925: Implement assist "Reorder field names" r=matklad a=geoffreycopin
This PR implements the "Reorder record fields" assist as discussed in issue #3821 .
Adding a `RecordFieldPat` variant to the `Pat` enum seemed like the easiest way to handle the `RecordPat` children as a single sequence of elements, maybe there is a better way ?
Co-authored-by: Geoffrey Copin <copin.geoffrey@gmail.com>
3944: Look up trait impls by self type r=matklad a=flodiebold
This speeds up inference in analysis-stats by ~30% (even more with the recursive solver).
There's a slight difference in inferred types, which I think comes from pre-existing wrong handling of error types in impls, so I think it's fine.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
3920: Implement expand_task and list_macros in proc_macro_srv r=matklad a=edwin0cheng
This PR finish up the remain `proc_macro_srv` implementation :
1. Added dylib loading code for proc-macro crate dylib. Note that we have to add some special flags for unix loading because of a bug in old version of glibc, see https://github.com/fedochet/rust-proc-macro-panic-inside-panic-expample/issues/1 and https://github.com/rust-lang/rust/issues/60593 for details.
2. Added tests for proc-macro expansion: We use a trick here by adding `serde_derive` to dev-dependencies and calling `cargo-metadata` for searching its dylib path, and expand it in our tests.
[EDIT]
Note that this PR **DO NOT** implement the final glue code with rust-analzyer and proc-macro-srv yet.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
todo!() "Indicates unfinished code" (https://doc.rust-lang.org/std/macro.todo.html)
Rust documentation provides further clarification:
> The difference between unimplemented! and todo! is that while todo!
> conveys an intent of implementing the functionality later and the
> message is "not yet implemented", unimplemented! makes no such claims.
todo!() seems more appropriate for assists that insert missing impls.
3905: add ellipsis field to hir pat record r=matklad a=JoshMcguigan
This PR corrects a `fixme`, adding an `ellipsis` field to the hir `Pat::Record` type. It will also be unlock some useful follow on work for #3894.
Additionally it adds a diagnostic for missing fields in record patterns.
~~Marking as a draft because I don't have any tests, and a small amount of manual testing on my branch from #3894 suggests it might *not* be working. Any thoughts on how I can best test this, or else pointers on where I might be going wrong?~~
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
Chalk now panics if we don't implement these methods and run with CHALK_DEBUG,
so I thought I'd try to implement them 'properly'. Sadly, it seems impossible to
do without transmuting lifetimes somewhere. The problem is that we need a `&dyn
HirDatabase` to get names etc., which we can't just put into TLS. I thought I
could just use `scoped-tls`, but that doesn't support references to unsized
types. So I put the `&dyn` into another struct and put the reference to *that*
into the TLS, but I have to transmute the lifetime to 'static for that to work.
