I added following lines to the cargo.toml of my project in order to benchmark my code:
[dev-dependencies]
criterion = "0.3"
[[bench]]
name = "samples"
harness = false
After running cargo bench, I get a lot of errors similar to the following:
Compiling criterion v0.3.4
error[E0603]: module `export` is private
--> C:\Development\Rust\cargo\registry\src\github.com-1ecc6299db9ec823\criterion-0.3.4\src\connection.rs:201:17
|
201 | #[derive(Debug, Deserialize)]
| ^^^^^^^^^^^ private module
|
note: the module `export` is defined here
--> C:\Development\Rust\cargo\registry\src\github.com-1ecc6299db9ec823\serde-1.0.123\src\lib.rs:275:5
|
275 | use self::__private as export;
The error message looks to me that there is a problem between serde and criterion. But I did not find this error message in either project issues, so there may be a hidden reason in my workspace.
Some additional information:
the project is compiled using the nightly toolchain
there is just one explicit dependency (proc macros) in the cargo.toml which transitively references syn, quote and proc-macro2
The serde version and serde_derive version in your dependency graph are mismatched. You need to use cargo update to bring them in sync. The two must have the identical version number always.
Related
In Rust, what is the difference between the two types of dependencies? It seems that the dev-dependency is conditional/ invoked at a certain time only.
If I include a crate in dev-dependencies, it gives me an error:
$ cargo build
Compiling <> ()
error[E0432]: unresolved import `uuid`
--> / |
28 | use uuid::Uuid;
| ^^^^ use of undeclared crate or module `uuid`
Cargo.toml content (clipped)
[package]
<clipped>
[dependencies]
<clipped>
[dev-dependencies]
uuid = { version = "1.0.0",features = ["serde", "v4"] }
But if I move it to the dependency section, then there is no error.
Closest related post: What is the difference between [dependencies] and [dependencies.dependency-name] in Cargo.toml?
Simple: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies
They are dependencies that only get included / built for examples, tests, and benchmarks.
Most importantly, they will not be included when you run a simple cargo build.
I'm trying to compile the sample code from the docx crate:
# Cargo.toml
[dependencies]
docx = "1.1.2"
//! main.rs
use docx::document::Paragraph;
use docx::DocxFile;
fn main() {
let docx = DocxFile::from_file("origin.docx").unwrap();
let mut docx = docx.parse().unwrap();
let para = Paragraph::default().push_text("Lorem Ipsum");
docx.document.push(para);
docx.write_file("origin_appended.docx").unwrap();
}
This is the full error I'm getting:
Compiling bzip2-sys v0.1.11+1.0.8
Compiling jetscii v0.4.4
Compiling quote v1.0.21
Compiling time v0.1.44
error: generic parameters may not be used in const operations
--> /home/thwart/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:109:13
|
109 | T::CONTROL_BYTE,
| ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
|
= note: type parameters may not be used in const expressions
error: generic parameters may not be used in const operations
--> /home/thwart/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:148:13
|
148 | T::CONTROL_BYTE,
| ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
|
= note: type parameters may not be used in const expressions
error: could not compile `jetscii` due to 2 previous errors
Why is Rust compiling jetscii? How do I fix this error?
This is caused by an unfortunate combination of a slightly-incompatible Rust update and old crates. The docx library depends on jetscii via this dependency tree:
docx v1.1.2
└── strong-xml v0.5.0
└── jetscii v0.4.4
You can view jetscii issue #56, jetscii pull request #39, and rust-lang/stdarch issue #248 for more info, but the basic summary is (courtesy of shepmaster):
TL;DR, older versions of Rust exposed the SIMD intrinsics in one way, that was changed, and a small number of crates (such as Jetscii) were affected.
The jetscii and strong-xml have long since been updated to accommodate this change but docx has not (no updates in over two years).
To workaround this issue your options are limited:
use Rust version 1.53
update docx with newer dependencies yourself
change libraries (consider docx-rs or docx-rust)
When trying to follow the instructions of the pathfinder library, i.e:
cd demo/native
cargo run --release
I get errors due to the compilation of the dependency winit version 0.19.3:
error[E0308]: mismatched types
--> /Users/yairchu/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.3/src/platform/macos/view.rs:209:9
|
205 | extern fn has_marked_text(this: &Object, _sel: Sel) -> BOOL {
| ---- expected `bool` because of return type
...
209 | (marked_text.length() > 0) as i8
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found `i8`
If I try changing the version used to the latest (which works fine for me) by changing Cargo.toml:
--- a/demo/native/Cargo.toml
+++ b/demo/native/Cargo.toml
## -43,7 +43,7 ## rev = "f3df871ac8c3926fe9106d86a3e51e20aa50d3cc"
[dependencies.winit]
-version = "<0.19.4" # 0.19.4 causes build errors https://github.com/rust-windowing/winit/pull/1105
+version = "0.27.2"
I still get the same errors!
Interestingly, I notice this in cargo's output:
Compiling winit v0.19.3
Compiling winit v0.27.2
It appears to now be building both the version I specified and the old version.
I'm lost. Also using --verbose didn't help elucidate why cargo chooses to build this specific dependency.
Is it using two versions of the same library in one executable?
How can I find out why cargo chooses to build this library? (so that I can update it to the working version)
Thanks! Rust noob
How can I find out why cargo chooses to build this library?
cargo tree elaborates on whose dependency is each sub-dependency.
Is it using two versions of the same library in one executable?
It is.
You can depend on different versions of the the same crate. This can be useful if you want to use one version of the dependency, but one of your own dependencies uses another version.
(thanks #Masklinn for the answers in the comments!)
I start with the cargo new tst. Then in the src/lib.rs I have:
pub struct Config {}
And src/main.rs looks like the following:
use crate::Config;
fn main() {}
This however does not compile:
> cargo run
Compiling tst v0.1.0 (/home/*/rust/book/tst)
error[E0432]: unresolved import `crate::Config`
--> src/main.rs:1:5
|
1 | use crate::Config;
| ^^^^^^^^^^^^^ no `Config` in the root
For more information about this error, try `rustc --explain E0432`.
error: could not compile `tst` due to previous error
But if I replace crate:: with the name of the crate like so:
use tst::Config;
fn main() {}
Then it just work:
> cargo run
Compiling tst v0.1.0 (/home/*/rust/book/tst)
warning: unused import: `tst::Config`
--> src/main.rs:1:5
|
1 | use tst::Config;
| ^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: `tst` (bin "tst") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 0.25s
Running `target/debug/tst`
The output for rustc --explain E0432 has the following quote, which if I understand it correctly means, that I can either use the name of a crate or simply crate:::
In Rust 2018, paths in use statements are relative to the current module
unless they begin with the name of a crate or a literal crate::, in which
case they start from the crate root. As in Rust 2015 code, the self:: and
super:: prefixes refer to the current and parent modules respectively.
Am I doing something wrong in here? Is there a way to use code from lib.rs without hardcoding the name of the crate?
> rustc --version
rustc 1.56.1 (Arch Linux rust 1:1.56.1-3)
> cat Cargo.toml
[package]
name = "tst"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
There is no way to refer to “the library crate in my package”; you must refer to it by its name. The Rust compiler doesn't (currently) know anything about other crates that happen to be in the same Cargo package; it just compiles one crate at a time.
In order for this to change, you would need to write a Rust RFC, which would need to include a description of why it would be valuable to have this feature — probably a stronger argument than “it would be less hardcoded”, since main depending on the library is almost certainly going to use library-specific names anyway, so the name of the library itself is a minor issue (unless, I suppose, you're creating many packages from a common template).
Cargo is not compiling with the following error:
$ cargo build
Compiling ring v0.12.1
error[E0583]: file not found for module `montgomery`
-->
C:\Users\jmccrae\.cargo\registry\src\github.com1ecc6299db9ec823\ring-0.12.1\src\arithmetic/arithmetic.rs:15:9
|
15 | pub mod montgomery;
| ^^^^^^^^^^
|
= help: name the file either arithmetic\montgomery.rs or arithmetic\montgomery\mod.rs inside the directory
"C:\\Users\\jmccrae\\.cargo\\registry\\src\\github.com-1ecc6299db9ec823\\ring-0.12.1\\src\\arithmetic"
The project was a new project with Cargo.toml modified to include a dependency to the most recent version (0.12.1) of the ring crate. The Cargo.toml is as follows:
[package]
name = "testring"
version = "0.1.0"
authors = ["John McCrae <john#mccr.ae>"]
[dependencies]
ring = "0.12.1"
The required file seems to actually exist:
$ ls C:\\Users\\jmccrae\\.cargo\\registry\\src\\github.com-1ecc6299db9ec823\\ring-0.12.1\\src\\arithmetic
arithmetic.rs montgomery.rs
The cargo version is cargo 0.25.0-nightly (930f9d949 2017-12-05) and it is running on MINGW.
Is there anything wrong with the compiler set-up?
This is an issue with Ring and Rust 1.24.0-nightly (2017-12-21). It also has an associated issue in the Rust repository.
To work around it, use an older version of Rust nightly (or avoid nightly if you can).