Error: NoTargetDir when running in a workspace with rust-toolchain 1.65.0 version
#188
Comments
|
Thank you for the issue! The error handling in Could you try creating a directory called The |
xFrednet
added
C-bug
|
@xFrednet the target directory exists. My setup is no different from any other cargo workspace in this regard. $ cargo new foo
Created binary (application) `foo` package
$ cd foo
$ echo 1.65.0 > rust-toolchain
$ cargo build
Compiling foo v0.1.0 (/home/veetaha/junk/foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.35s
$ cargo marker --lints 'marker_lints = "0.1.1"'
Error: NoTargetDir |
|
Interesting, I'll investigate this. Thnak you :) |
|
FWIW: I was looking into using marker for a large app at work, and ran into the same issue, I made a minimal clone of the marker_lints crate and removed all of the testing code, and running |
|
Thank you for the feedback! This will be fixed in the next version, planned for the next rust release. I plan to check for a |
|
Doing a little digging and some good old fashioned |
What path forwarding do you mean in this case? If you're referring to the If you're asking why cargo uses The goal of the function, that throws the error, is to find the target directory. I used I can think of the following solutions to investigate:
I believe 1 and 2 would be the best solutions if they work. We might also want to investigate if Btw. since you started digging though Marker, I've started writing some contributor documentation: #199 Not sure if it contains any additional information for you, since you already got the project running, but it might still be useful. Thank you for helping with this issue! |
Ah, I'm sorry. I need to be more aware of my expressions, not everyone online uses my local jargon. I'll be looking into option 1 first, (or maybe 2 if that's just not possible) as it seems extremely likely to me that there are other places this inconsistency has occurred and that the find target dir is just the one that happened to crop up first. It also seems like since cargo-metadata is just a wrapper over rustc, we really want everything to line up version wise, otherwise it seems extremely likely that we'll find a similar version issue in the future. |
"The path forward" is a common phrase in English, so please continue using it, also on GH. My mind was just so focussed on file paths, that it didn't consider the sentence as a whole ^^ This bug is now fixed with your PR. I've created a new issue #205 for the fourth option, to allow users to specify the target directory manually :) |
217: Fixed toolchain version drift, improved error handling, config loading and refactoring. r=xFrednet a=nitkach ### This PR solves several problems ## Problem 1 After resolving this issue #188, this problem was revealed. I didn't create an issue, I just fixed it in this PR. When `cargo` of the new version tries to call `rustc` of the old version and pass it arguments that it does not support, the program breaks. This happens when executing a command in `cargo_metadata_command()`. Description of the situation in the diagram:  Inside `MetadataCommand::new()` creates `cargo metadata` which calls `rustc`. It, in turn, takes the toolchain from `PATH="~/.rustup/toolchains/1.65.0-*"` ## Problem 2 Also in repository with 1.65.0 in rust-toolchain file the following error occurs: ``` $ cargo marker Compiling Lints: error: the `-Z` flag is only accepted on the nightly channel of Cargo, but this is the `stable` channel See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels. Error: LintCrateBuildFail ``` <!-- Reproduces if there is no `cargo_marker` in the current `Cargo.toml` dependencies. The `PATH` additionally specifies the path to `cargo-marker`. --> Diagram of command calls and environment variables:  The command `cargo build ... -Z unstable-options ...` uses a stable toolchain, despite the specified `RUSTUP_TOOLCHAIN=nightly-2023-07-03`. Then `rustc` is called, the stable toolchain is taken from `PATH` and a command execution error occurs. Cannot use the arguments available on the nightly version of `cargo` in the stable channel. --- To fix this, I changed the `cargo_command()` of `Toolchain`. Now the ``` rustup run {toolchain} cargo ``` is being created. This makes `rustup` a proxy for `cargo`, guaranteed to call `cargo` with the specified `toolchain`. --- ### Cargo workspace manifest location Now the location of the workspace manifest file is obtained by executing the `cargo_locate_project` method on the `Cargo` type. The `rustup run {toolchain} cargo locate-project --workspace` command is executed. --- #### Error handling I have plan to refactor error handling in future PR. I have removed the error codes from `ExitStatus`, as they do not work as I assume. In the terminal, it always shows that `(exit code: 1)` is returned. https://github.com/nitkach/marker/blob/b95435d77065210bbe38e6995f35bd165f280612/cargo-marker/src/exit.rs#L81-L83 Adding the `Fatal` variant with a description and the source of the error makes creating errors easier. --- #### Parsing TOML as strongly typed data structures For parsing `toml`, I added the use of rust types, which deserializes the document into a structure with fields. --- #### `Display` error for toml file while parsing I also noticed that it is possible to output errors in more readable way `Debug`: ``` Can't parse config: Error { inner: Error { inner: TomlError { message: "data did not match any variant of untagged enum LintDependency", original: Some("[workspace]\nmembers = [\n \"cargo-marker\",\n \"marker_adapter\",\n \"marker_api\",\n \"marker_rustc_driver\",\n \"marker_utils\",\n \"marker_lints\",\n \"marker_uitest\",\n \"marker_uilints\",\n]\nresolver = \"2\"\n\n[workspace.metadata.marker.lints]\nmarker_lints = { foo = \"./marker_lints\" }\n"), keys: ["workspace", "metadata", "marker", "lints", "marker_lints"], span: Some(245..271) } } } ``` `Display`: ``` Can't parse config: TOML parse error at line 15, column 16 | 15 | marker_lints = { foo = "./marker_lints" } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ data did not match any variant of untagged enum LintDependency ``` --- #### Some code changes I'm learning how to use iterators. Where the `mut` variable and the `for` loop were used, I replaced that with iterators. In some places, an immutable `Vec<T>` was created, which I changed to an `[T]`. Co-authored-by: Nikita <nikita_tkachev_2001@mail.ru>
The error is simply
Our cargo workspace is sitting on an older version of rust toolchain, although we are planning to upgrade soon, but the error is not informative, it doesn't show what actually went wrong. Only by inspecting the code of
cargo-markerand experimenting I figured out the rust version was causing this.To reproduce this you may create a crago workspace with
rust-toolchainfile with1.65.0in it.The version of cargo-marker is
0.1.1andmarker_lintsis0.1.1as wellThe text was updated successfully, but these errors were encountered: