RA does not work at all when offline

[RalfJung]

I tried to do a bit of coding on rustc while on a plane without internet, and noticed that RA handles this situation quite badly. cargo metadata fails because it cannot refresh the index, and then basically nothing works, even though everything needed should be available offline. In particular, not even "check on save" does anything -- I had to run ./x.py check by hand. That worked perfectly fine, demonstrating that RA could also have run x.py as usual and show the diagnostics in the editor.

rust-analyzer version: ad6810e 2022-06-06 stable

rustc version: rustc 1.63.0-nightly (e094492 2022-05-31)

relevant settings:

{
    "rust-analyzer.checkOnSave.enable": true,
    "rust-analyzer.checkOnSave.overrideCommand": [
        "./x.py",
        "check",
        "--json-output",
        "library/std",
        "compiler/rustc",
    ],
    "rust-analyzer.rustfmt.overrideCommand": [
        "./build/x86_64-unknown-linux-gnu/stage0/bin/rustfmt",
        "--edition=2021"
    ],
    "rust-analyzer.procMacro.enable": false,
    "editor.formatOnSave": false,
    "files.watcherExclude": {
        "*rustc*/src/llvm-project/**": true,
        "*rustc*/build/**": true,
    },
    "files.exclude": {
        "src/llvm-project/**": true,
        "build/**": true
    },
    "rust-analyzer.cargo.buildScripts.enable": false,
    "rust-analyzer.rustc.source": "./Cargo.toml",
    "rust-analyzer.hover.actions.references.enable": true,
}

[jhgg]

Does it work if you add net.offline = true to your cargo config?

[RalfJung]

That only changes the error message to

rust-analyzer failed to load workspace: Failed to read Cargo metadata from Cargo.toml file /home/r/src/rust/rustc/Cargo.toml, cargo 1.63.0-nightly (39ad1039d 2022-05-25): Failed to run `"cargo" "metadata" "--format-version" "1" "--manifest-path" "/home/r/src/rust/rustc/Cargo.toml" "--filter-platform" "x86_64-unknown-linux-gnu"`: `cargo metadata` exited with an error: error: failed to download `minifier v0.2.1`

Caused by:
  attempting to make an HTTP request, but --offline was specified

[jhgg]

Hmm, I would think that if the local cache has all the crates in them it should work fine...

[RalfJung]

This might be related to rust-lang/cargo#10096, where cargo metadata insists to do some work that is IMO entirely unnecessary.

I see two orthogonal issues here:

• cargo metadata failed when it possibly should not have
• RA completely bails when cargo metadata fails, even though I would think it can still run ./x.py check and render the resulting diagnostics in the editor

[flodiebold]

RA completely bails when cargo metadata fails, even though I would think it can still run ./x.py check and render the resulting diagnostics in the editor

Without Cargo metadata, RA doesn't have a project and basically can't do anything. Sure, in theory it could blindly run check to report errors, but 1) check-on-save is really a bolted-on-top workaround to the fact that RA doesn't have most diagnostics built-in yet, so we don't really want to make fundamental changes to the architecture based on it, and 2) I think in most cases, if cargo metadata fails, you'd expect cargo check to fail as well. This seems like a rather special case.

[lnicola]

Should there be an x.py metadata? 😄

[blaa]

That's not only "I'm on an airplane" case, but also "I work in airgapped environment and would like to use Rust". We do build docker image with all cargo dependencies on a networked host and then move it inside environment without network access.

I believe analyzer worked ok about 9 months ago, but we could have used older RA back then too.

[kting28]

I think the issue is that when CargoWorkspace::fetch_metadata() is called, --offline is not passed. I briefly verified in an offline environment. Not clear to me how RA would know it's supposed to be offline. May be it needs to read the offline = true flag under [net] in Cargo.toml first...

[lnicola]

Note that even --offline won't help in most cases.

[kting28]

Note that even --offline won't help in most cases.

right, it only works if things are in the cargo cache before the internet access is removed. Have you tried setting the env var CARGO_NET_OFFLINE=true ? cargo metadata seems to honor this.

[djc]

FWIW, I ran into this yesterday on an airplane as well. I managed to work around this in the following way:

• Quit the editor (in my case, VS Code)
• Kill any "stuck" RA processes
• Run cargo check --all-targets --offline in a terminal to update the Cargo.lock file
• Then restart the editor

(Separately, editing dependencies required some manual dexterity, but that's more of a Cargo issue.)

In my mind the ideal solution here would be that RA uses some connectivity canary (like a trivial DNS request to Google or Cloudflare DNS servers) to assess whether it should try applying --offline/CARGO_NET_OFFLINE.

[lnicola]

In my mind the ideal solution here would be that RA uses some connectivity canary (like a trivial DNS request to Google or Cloudflare DNS servers) to assess whether it should try applying --offline/CARGO_NET_OFFLINE.

If we do (#15146), it should be disabled by default, because everyone will go up in arms about it ("rust-analyzer is sending your personal information to Cloudflare!").

[djc]

Well, I'm fine with a HTTP request to rust-lang.org if we prefer that, instead.