Rls: tracking issue: wishlist

[nrc]

This is a grab bag of things I'd like the RLS to be able to do some day - some are easy, some are hard. I'll add more as I think of them.

Search/navigation

• type info for path segments
• find impls of trait
• find impls for type
• find overriding/overriden method
• find (transitive) sub/super traits
• find callers/callees
• text search/regex search
• identifier search (already in RLS, but not exposed in LSP)
• goto type (for expressions, etc.)
• goto def for macros
• for extern crate, show all names imported into the program (with find all uses links for each name)
• for a module or crate, show all public names (including via paths)

Refactoring

• [x] glob -> list import
• remove unused imports
• alias an import
• inline module <-> file module <-> directory module
• module <-> crate
• move code between modules, adjusting imports as necessary
• extract/line variable
• extract function/inline function
• bare function <-> method (note autoref for users)
• match <-> if let
• elide/reify lifetimes
• change local/arg <-> field of a struct (e.g., fn foo(x, y, s) { ..x..y..} <-> fn foo(s) { ..s.x...s.y... }

Code generation

• external mod
• impl for type/type + trait
• auto-imports
• create new function for struct
• add/erase type/lifetime arg
• match, given an expression
• generate function stub from call

Errors

• show notes/other sub-errors
• gracefully link errors with their notes
• [x] apply suggestions

Performance

• lazy compilation
• compiler-driven code completion (obsoletes Racer)

Visualisation, etc.

• macro expansion, partial expansion
• visualise lifetimes
• better support for documentation

Applicability

• non-cargo projects
• projects with multiple workspaces, targets, etc. (https://github.com/rust-lang-nursery/rls/issues/132)

Misc

• debugging (probably not in the RLS, but perhaps we should think of integration)
• build commands
  
  
  
  • doing non-check builds, running tests
  
  
  • customising builds, passing args to the RLS
  
  

[Nashenas88]

Should we list dependencies for some of these? For example, lifetime visualization depends on the MIR borrow checker to be implemented as anything done for the current borrow checker will be thrown away relatively soon.

[nrc]

Should we list dependencies for some of these

These are mostly things which are not yet on the horizon of implementation, so I don't think it would be super-helpful

[gaudecker]

Live unit testing. It essentially highlights code that is either covered by passing or failing tests, or not covered at all.

I think this could be a pretty powerful feature, and definitely worth giving some thought.

[ruabmbua]

Add clippy to the Errors section. Would be nice to enable clippy plugins to reside in the RLS.

[matklad]

• Search/replace based on AST: https://www.jetbrains.com/help/idea/2016.3/structural-search-and-replace.html

• Scripting API, such that one can write project specific assists, inspections and fixes.

[retep998]

I'd like to have a way to specify which cargo features to enable. Otherwise RLS is useless for winapi because practically everything is gated by a cargo feature.

[paulirotta]

Raspberry Pi support.

error: component 'rls-preview' for 'armv7-unknown-linux-gnueabihf' is unavailable for download

[martijnarts]

I'm wondering if it'd be possible to have separate issues for these, so we could subscribe to them separately (and maybe show support/priorities with +1s?)

The "match, given an expression" especially is interesting to me.