Respecting .cargo/config.toml

[Veykril]

This is more of a collection of some issues floating around regarding the .cargo/config.toml and general discussion of how to solve these.

• Respect the build.target key for analysis(can be worked around mostly with "rust-analyzer.cargo.target"): Feature request: Support using target from .cargo/config.toml #6604 Any way to temporarily change default target? #5904 Rust-analyzer not respecting default target #8430
• Respect features set via rustflags for analysis cfg calculation doesn't seem to respect -Ctarget-cpu=native in .cargo/config.toml #8480
• rustflags causes rebuilds rustflags in .cargo/config cause rebuilds when running "cargo build" #5828

As pointed out in #5904 (comment):

I don't see any reason right now why .cargo/config wouldn't already have an effect -- we're just calling cargo check. Or do you mean also using the target from .cargo/config for analysis (i.e. rust-analyzer.cargo.target)? Maybe cargo metadata doesn't use that configuration, or we call it in a way that prevents that; that might be worth investigating. We probably don't want to parse .cargo/config ourselves though.

We probably do not want to parse this ourselves but cargo metadata doesn't seem to expose this info in its output either, see https://doc.rust-lang.org/cargo/commands/cargo-metadata.html#output-format. So we either have to parse it ourselves or get the relevant info to be emitted by cargo metadata from what I can tell.

[flodiebold]

Note that we explicitly pass --filter-platform to cargo metadata, so I'm not sure whether it would even be possible for it to respect the target config.

[Veykril]

Hm, ye that might be a problem. I wonder if parsing the config might be not such a bad idea though, we wouldn't have to parse everything but a few things we are interested in anyways(currently build.rustflags and build.target)?
Though I guess it becomes a bit more complex when it comes to target.<triple>.rustflags.

[Veykril]

Then again we don't have toml in our dependency tree and I don't think we would want to add that. I wonder if it would make sense to add a subcommand to cargo to emit the configuration as json similar to what metadata does for packages? That way cargo would also be the one to resolve the paths to the configs not requiring us to search for them in the appropriate folders.

Edit: Turns out this is already an unstable thing rust-lang/cargo#9301 🎉

[Veykril]

Actually, I think we can get by with this rust-lang/cargo#9357 once it lands?
Nevermind, we can use it to resolve rustflags but not to get the target triple defined in the cargo config.

[Veykril]

Managed to throw a working branch together: Veykril@8989fb8

This uses unstable cargo features, cargo config get to read the target triple out of the config to pass to cargo metadata --filter-platform and cargo rustc --print to read out the rustc_cfgs. If those commands fail they fall back to what we previously used, namely invoking rustc directly.

Now the question is, as we don't really use nightly apis, does not using unstable things also apply to cargo when we have fallbacks in place if those commands fail?

Anyways at least we got a (future) solution to these problems.

[Veykril]

The only open issue about this now is #5828, which I'm unsure what the cause of is. I'll close this issue in favor of the already opened issue there since its the only remaining one.