sccache causes rls builds to fail with "multiple input filenames provided"

[jrobsonchase]

Setting RUSTC_WRAPPER=$HOME/.local/bin/sccache seems to cause rls to fail to compile with multiple input filenames provided. Tested with sccache 2.5 and rls-preview 0.125.0-nightly (dee42bd 2018-02-04).

vscode rust settings:

    "rust-client.channel": "nightly",
    "rust-client.logToFile": true,
    "rust-client.revealOutputChannelOn": "info",

Log with RUSTC_WRAPPER set and RUST_LOG=rls=debug:

DEBUG 2018-02-07T16:35:50Z: rls::server: Language Server starting up. Version: 0.125.0-nightly (dee42bd 2018-02-04)
{"message":"multiple input filenames provided","code":null,"level":"error","spans":[],"children":[],"rendered":"error: multiple input filenames provided\n\n"}
 INFO 2018-02-07T16:35:50Z: rls::build::cargo: cargo failed
cause: Could not compile `rls-testing`.
stdout: 
DEBUG 2018-02-07T16:35:51Z: rls::server: Method not found: textDocument/didClose

[nrc]

I'm not sure how sccache works, but I don't think you will be able to use it with the RLS since we use our own version of rustc, so I don't think that will work with RUSTC_WRAPPER

[Dushistov]

Oh, I thought that rls are just not working yet. Will retry without sccache

[kohensu]

Is is possible for RLS to remove RUSTC_WRAPPER from the environment that is passed to rustc ?
(as long as this feature is not supported by RLS)

This will make RLS working as usual in an environment that use sccache

[prasannavl]

^ -- I think that's a reasonable thing to do.

My logs are flooded with the same multiple input provided. And I don't want to stop using sccache just because of this. If that is indeed the only problem, perhaps, make RLS remove it from it's own env before starting rustc?

It's seems like what must be a simple solution. I don't know why this issue is open for so long unfixed.

[mstange]

Is there a workaround for this? I think this bug is the reason why the VSCode rust extension doesn't work for me at all.