4406: Update cargo-metadata r=matklad a=edwin0cheng
This PR update `cargo-metadata` to 0.10.0 and it also relax the` serde-derive` deps to 1.0 for tests in `proc-macro-srv`.
cc @robojumper
r= @matklad , I think you would have something to say related to https://github.com/serde-rs/json/issues/647#issue-593788429 ?
4410: Improve wording in comment r=matklad a=edwin0cheng
4411: do not remove then block when you unwrap else block #4361 r=matklad a=bnjjj
close#4361
4417: Omit default types in HirDisplay SourceCode mode r=matklad a=TimoFreiberg
Closes#4390
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
This starts the transition to a new method of documenting the cfgs that are
enabled for a given crate in the json file. This is changing from a list
of atoms and a dict of key:value pairs, to a list of strings that is
equivalent to that returned by `rustc --print cfg ..`, and parsed in the
same manner by rust-analyzer.
This is the first of two changes, which adds the new field that contains
the list of strings. Next change will complete the transition and remove
the previous fields.
4329: Look for `cargo`, `rustc`, and `rustup` in standard installation path r=matklad a=cdisselkoen
Discussed in #3118. This is approximately a 90% fix for the issue described there.
This PR creates a new crate `ra_env` with a function `get_path_for_executable()`; see docs there. `get_path_for_executable()` improves and generalizes the function `cargo_binary()` which was previously duplicated in the `ra_project_model` and `ra_flycheck` crates. (Both of those crates now depend on the new `ra_env` crate.) The new function checks (e.g.) `$CARGO` and `$PATH`, but also falls back on `~/.cargo/bin` manually before erroring out. This should allow most users to not have to worry about setting the `$CARGO` or `$PATH` variables for VSCode, which can be difficult e.g. on macOS as discussed in #3118.
I've attempted to replace all calls to `cargo`, `rustc`, and `rustup` in rust-analyzer with appropriate invocations of `get_path_for_executable()`; I don't think I've missed any in Rust code, but there is at least one invocation in TypeScript code which I haven't fixed. (I'm not sure whether it's affected by the same problem or not.) a4778ddb7a/editors/code/src/cargo.ts (L79)
I'm sure this PR could be improved a bunch, so I'm happy to take feedback/suggestions on how to solve this problem better, or just bikeshedding variable/function/crate names etc.
cc @Veetaha
Fixes#3118.
Co-authored-by: Craig Disselkoen <craigdissel@gmail.com>
Co-authored-by: veetaha <veetaha2@gmail.com>
4166: Defining a default target to support cross-compilation targets r=matklad a=FuriouZz
Related to #4163
Co-authored-by: Christophe MASSOLIN <christophe.massolin@gmail.com>
4125: Avoid lossy OsString conversions r=matklad a=lnicola
This is a bit invasive, and perhaps for not much benefit since non-UTF-8 environment variables don't work anyway.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
This commit is a fixup of a bug I introduced by using a PackageId to refer to a crate when its name conflicts with a dependency.
It turns out the package id currently is `name version path` while cargo expects `name:version` as argument.
Until now cargo commands with the -p flag would pass the package name only.
It doesn't play super well with the toml Renaming dependencies feature.
This commit specifies the package name and version when a cargo command is run with the -p flag,
to avoid ambiguities.
As stated by matklad, reading the stderr
should be done alngside with
stdout via select() (or I guess poll()),
there is no such implementation in stdlib,
since it is quite low level and platform-dependent and it
also requires quite a bit of unrelated code we don't use it for now.
As referenced by bjorn3, there is an implementation of the needed read2() function
in rustc compiletest. The better solution will be to extract this function
to a separate crate in future:
https://github.com/rust-analyzer/rust-analyzer/pull/3632#discussion_r395605298
