Rls: Auto-complete limitations tracker

[prasannavl]

Copying issue over from: https://github.com/rust-lang-nursery/rls-vscode/issues/120#issuecomment-340596260

Autocomplete provided by the language service at the moment is very flaky. While the documentation claims auto-complete, the current behavior often ends up in unpleasant surprise. There're also a bunch of other issues here at RLS which unfortunately seems to be pointed at racer. eg: https://github.com/rust-lang-nursery/rls/issues/516, https://github.com/rust-lang-nursery/rls/issues/517

But I think these are issues that have to be handled by RLS in long-term issues, as also agreed by @jwilm in the referred issue above. With that in mind, I'm copying the issue here, as hopefully a blanket issue for tracking all the auto-complete specific limitations in the long-term.

Are-We-Autocomplete-Yet repo: https://github.com/prasannavl/rust-away

A simple repo that has the below sample plus more as source code with comments that makes it easy to test if all the scenarios that are expected from an modern day auto-completion service to work. Hopefully, this serves as both a test to language services, and also to fill in the gaps in the documentation on what to expect.

Sample

extern crate rand;
extern crate primal;

use std::io;
use std::cmp::Ordering;
use rand::Rng;

fn main() {    
    println!("Hello, world!");

    use std::collections::HashMap;
    let teams  = vec![String::from("Blue"), String::from("Yellow")];
    let mut initial_scores: Vec<String> = std::vec::Vec::new();
    initial_scores.push("10".to_string());

    let i = initial_scores.iter();

    let scores: HashMap<_, _> = teams.iter().zip(initial_scores.iter()).collect();

    let n = rand::thread_rng().gen_range(1, 10);

    println!("Guess the number! ({})", n);

    let mut guess = String::new();
    io::stdin().read_line(&mut guess)
        .expect("failed to read line");

    let guess_number: u32 = guess.trim().parse()
        .expect("not a number!");

    match guess_number.cmp(&n) {
        Ordering::Less    => println!("Too small!"),
        Ordering::Greater => println!("Too big!"),
        Ordering::Equal   => println!("You win!"),
    }

    println!("Your number: {}", guess);
    println!("Good bye!");
}

Observations:

• let teams = vec![String::from("Blue"), String::from("Yellow")]; - Doesn't seem to recognize the type of "teams", and no autocomplete on the variable beyond this.
• However the next line - defined by Vec:new() works.
• let i = initial_scores.iter(); - into_iter is shown - but not iter(). It seems to be a partial autocomplete list.
• let i = initial_scores.iter(); - Type i unresolved, and as such no auto-complete further (possibly due to the above)
• let scores: HashMap<_, _> = teams.iter().zip(initial_scores.iter()).collect(); - Unresolved type (possibly related again to the above).
• let mut guess = String::new(); - Type recognition works. But auto-complete is partial - methods like cmp not available.
• let guess_number: u32 = guess.trim().parse() .expect("not a number!"); - No autocomplete even though the type is explicitly given.
• primal:: - Only displays test mod inside. All other types are missing. This is just an example. Most cargo package don't show up with proper auto-complete.

[nrc]

Currently autocomplete is only provided by Racer. We cannot use the compiler because latency is too high. Once we have lazy/incremental compilation to type checking than we should be able to use data from the compiler to drive code completion (see #6). At that point there will be a completely different set of issues because the entire system for completion will be changed. Given that, there is not much point in tracking current weaknesses in completion. Since compiler-driven completion is tracked in #6, I'll close this issue (and the other code completion issues). But we do plan to make these improvements!

[prasannavl]

@nrc, While the compiler-backed auto complete is tracked by the other issue - that's an implementation detail of the auto-complete provider. Semantically, I find it a little weird that you're referring to it and closing this. You're the maintainer, so I'll defer to you on how best to keep track :) .. But might I suggest leaving it open until the 'dev-experience' expected out of rls (which is kinda the tracking point of the issue), is resolved to a reasonable extent?