Autocomplete fails on Vec after custom allocators support was added

[andylizi]

Description

Autocomplete fails to show any result under specific circumstances:

This problem only seems to happen on rust nightly. It consistently disappears after rustup default stable and restarting the RA server. The bytes crate doesn't seems to have anything cfg'ed on nightly. Functions in other traits (e.g. std::io::Read) seems to work fine.

Environment

• RA: 2020-11-23 (cadf0e9)
• VSCode: 1.51.1
• Rust: 1.50.0-nightly (1c389ffef 2020-11-24)

Minimal reproducible example

1. Switch to nightly toolchain
2. Add bytes = "0.6" to dependencies
3. Add use bytes::{BytesMut, buf::Buf};
4. Write let buf = BytesMut::new();
5. Try to complete on buf.<|>

(Verified to be reproducible in Windows Sandbox using a fresh install of Rust, VSCode, and RA without changing any settings)

This is maybe related to #6612, but I'm not sure because a) it doesn't complete no matter what I do or how long I wait; and b) it somehow only appears in Rust nightly.

Edit: see #6668 (comment)

[bjorn3]

If you write let a = Vec::new() does it show the type of a in an inlay hint like it does for buf in the gif when you use nightly rustc?

[andylizi]

It shows Vec<{unknown}> in inlay hint and autocompletion on a works fine.

[andylizi]

Actually no, autocomplete fails to give any result on a, just like buf. I forgot to switch back to nightly before.

But other types, like str String File Rc and even VecDeque works. I'm not sure what's the pattern here...

[SomeoneToIgnore]

The symptoms are familiar to #6672

The last working version for me is nightly-2020-10-26-x86_64-unknown-linux-gnu - rustc 1.49.0-nightly (4760b8fb8 2020-10-25)

so maybe nightly after all.

[andylizi]

For me the latest working version is da3846948 2020-11-21 and it fails on a0d664bae 2020-11-22, so it shouldn't be the same issue? The only major difference between them appears to be rust-lang/rust#78461.

Oh! I see. BytesMut derefs to Vec<u8>, so that's why most of the other types don't have the same issue.

use std::ops::Deref;

fn main() {
    let test = Test { vec: vec![] };
    test.<|>        // Fails to complete
}

struct Test {
    vec: Vec<u8>
}

impl Deref for Test {
    type Target = Vec<u8>;

    fn deref(&self) -> &Self::Target {
        &self.vec
    }
}

[jonas-schievink]

fn f() {
    let mut v = Vec::new();
    v.<|>
}

thread '<unnamed>' panicked at 'index out of bounds: the len is 1 but the index is 1', crates/hir_ty/src/lib.rs:1007:31
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
   1: core::panicking::panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
   2: core::panicking::panic_bounds_check
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:62
   3: hir_ty::TypeWalk::subst_bound_vars_at_depth::{{closure}}
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/lib.rs:1007
   4: <hir_ty::Ty as hir_ty::TypeWalk>::walk_mut_binders
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/lib.rs:1083
   5: <hir_ty::Substs as hir_ty::TypeWalk>::walk_mut_binders
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/lib.rs:373
   6: <hir_ty::Ty as hir_ty::TypeWalk>::walk_mut_binders
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/lib.rs:1068
   7: hir_ty::TypeWalk::subst_bound_vars_at_depth
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/lib.rs:1003
   8: hir_ty::TypeWalk::subst_bound_vars
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/lib.rs:995
   9: hir_ty::method_resolution::transform_receiver_ty
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/method_resolution.rs:728
  10: hir_ty::method_resolution::is_valid_candidate
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/method_resolution.rs:654
  11: hir_ty::method_resolution::iterate_inherent_methods
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/method_resolution.rs:595
  12: hir_ty::method_resolution::iterate_method_candidates_by_receiver
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/method_resolution.rs:492
  13: hir_ty::method_resolution::iterate_method_candidates_with_autoref
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/method_resolution.rs:431
  14: hir_ty::method_resolution::iterate_method_candidates_impl
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/method_resolution.rs:393
  15: hir_ty::method_resolution::iterate_method_candidates
             at /home/jonas/dev/rust-analyzer/crates/hir_ty/src/method_resolution.rs:339
  16: hir::code_model::Type::iterate_method_candidates
             at /home/jonas/dev/rust-analyzer/crates/hir/src/code_model.rs:1595
  17: completion::completions::dot::complete_methods
             at /home/jonas/dev/rust-analyzer/crates/completion/src/completions/dot.rs:50
  18: completion::completions::dot::complete_dot
             at /home/jonas/dev/rust-analyzer/crates/completion/src/completions/dot.rs:26
  19: completion::completions
             at /home/jonas/dev/rust-analyzer/crates/completion/src/lib.rs:123
  20: ide::Analysis::completions::{{closure}}
             at /home/jonas/dev/rust-analyzer/crates/ide/src/lib.rs:468
  21: base_db::CheckCanceled::catch_canceled::{{closure}}
             at /home/jonas/dev/rust-analyzer/crates/base_db/src/lib.rs:62
  22: std::panicking::try::do_call
             at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:381
  23: std::panicking::try
             at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:345
  24: std::panic::catch_unwind
             at /home/jonas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:382
  25: base_db::CheckCanceled::catch_canceled
             at /home/jonas/dev/rust-analyzer/crates/base_db/src/lib.rs:62
  26: ide::Analysis::with_db
             at /home/jonas/dev/rust-analyzer/crates/ide/src/lib.rs:530
  27: ide::Analysis::completions
             at /home/jonas/dev/rust-analyzer/crates/ide/src/lib.rs:468
  28: rust_analyzer::handlers::handle_completion
             at /home/jonas/dev/rust-analyzer/crates/rust-analyzer/src/handlers.rs:565
  29: rust_analyzer::dispatch::RequestDispatcher::on::{{closure}}
             at /home/jonas/dev/rust-analyzer/crates/rust-analyzer/src/dispatch.rs:66
  30: rust_analyzer::thread_pool::TaskPool<T>::spawn::{{closure}}
             at /home/jonas/dev/rust-analyzer/crates/rust-analyzer/src/thread_pool.rs:22
  31: <F as threadpool::FnBox>::call_box
             at /home/jonas/.cargo/registry/src/github.spider-man.dpdns.org-1ecc6299db9ec823/threadpool-1.8.1/src/lib.rs:95
  32: threadpool::spawn_in_pool::{{closure}}
             at /home/jonas/.cargo/registry/src/github.spider-man.dpdns.org-1ecc6299db9ec823/threadpool-1.8.1/src/lib.rs:769
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Looks like we aren't accounting for default type parameters somewhere.

[jonas-schievink]

Self-contained repro (minus Deref):

use core::ops;

pub struct Vec<T, A = ()> {
}

impl<T> Vec<T> {
    pub const fn new() -> Self {
    }
}

impl<T, A> ops::Deref for Vec<T, A> {
    type Target = [T];

    fn deref(&self) -> &[T] {
    }
}

and then again

fn f() {
    let mut v = Vec::new();
    v.<|>
}

[flodiebold]

Hmm. I fear that might be our slightly hacky Deref handling... (I'd recommend turning the self-contained repro into a test in hir-ty by adding Deref, and then seeing whether those logs get hit.)

[flodiebold]

@jonas-schievink I can't reproduce the problem with your repro, with current RA and rustc 1.48 🤔

E.g.

[jonas-schievink]

You need nightly Rust, custom allocator support for Vec is still nightly-only

[flodiebold]

But why would your self-contained repro depend on custom allocator support in Vec?

[flodiebold]

You're right though, it reproduces with nightly 🤔

Edit: It's not related to Vec or Deref at all, I think. It happens with completion on a slice as well.

Edit 2: I suspect const generics.