Determine return types for macros (such as vec![])

[Wilfred Hughes]

I've seen issues discussing autocomplete on macros and jumping to definitions, but I've also noticed that racer can't tell vec![] is of type Vec.

As a result, racer can't offer any completions here:

fn main() {
    let m = vec![];
    m.
}

even though using an explicit Vec creation is fine:

fn main() {
    let m = Vec::new();
    m.
}

[nxnfufunezn]

It works for me..

rustc 1.2.0 (082e47636)
cargo 0.4.0-nightly (15b497b)
NeoVIM 0.0.0-alpha+201509041956

[Jonas Schievink]

Does it work when leaving out the type annotation of the let binding?

[nxnfufunezn]

nope! 😞

[Phil Dawes]

Hi @Wilfred: Yes, I'm afraid this is because racer doesn't support macros yet.
(I guess vec![] could be added as a special case, but personally I'm more interested in working on getting better compiler support to handle this)

[Jason Schein]

@phildawes how difficult would it be to get autocompletion for external libraries that define types using macros (or impls traits using macros). This is the feature I've missed most and it seems that if we could expand the macros and save the result somewhere, then we could just do autocompletion using the generated code.

I have very little knowledge of programming language design, parsing, compilers ect... so this is all just based on general intuition. If this is a reasonable approach I'd be willing to take a crack at implementing it.

[Phil Dawes]

Hi @echochamber. I think your intuition is correct about expanding macros, this was how I was originally planning to handle them in racer. There are a couple of thorns:

• often the generated code is too complex for racer's type inference to work on, This might not be the case for vec![] though
• I'm working on levering rustc to get better (perfect) type inference, and macros should just fall out as a consequence of this.

The second point is the main reason I haven't attempted to put macros into racer yet. I'd say feel free to try and add them (this would be great!), but be aware that a rustc enabled version might invalidate this work in the future.

[Jason Schein]

@phildawes That makes sense. In that case, I'd rather focus my effort elsewhere.

I'm working on levering rustc to get better (perfect) type inference, and macros should just fall out as a consequence of this.

Is this something that would benefit from the assistance of someone like myself, with no experience in language design and language tools development, or is there somewhere else I'd be more suited to contribute? My reasons for wanting to contribute are that I use racer and would like to help see it improved but also as a learning experience for myself on the workings of programming language internals and tooling development. However, it would still be nice if my efforts could have some net benefit for the project. I ask because I'm aware that my learning process might be more of an overall burden on you and your time you'd spend working on racer rather than a benefit.

[Phil Dawes]

Hi @echochamber,

Sorry for the delay in replying. Things are a bit up in the air at the moment with regard to racer because there's the opportunity of using the rustc compiler. There are changes to make the rust compiler more incremental, and also the tools subteam are interested in rust IDE tooling.

I'm currently building prototypes trying to work out how to solve the problems of interfacing racer with rustc and running rustc against incomplete code, but it is exploratory work so there's not much I can offer in the way of an introductory project at this point. Hopefully in a month or so it will have settled down and I'll have a better handle on what the direction will be.

[Jason Schein]

@phildawes Sounds good, in that case I'll look forward to seeing your work later on.

[Bruno Bigras]

Any progress?