This question already has answers here:
How is it possible to keep Rust module documentation in separate Markdown files?
(3 answers)
Closed 3 years ago.
If the readme Cargo.toml key is set, doc.rs renders the README on the crate's index page. Is there a way to emulate this when running cargo doc locally?
If I add:
#![doc = r###"contents
of
README.md
here
"###]
as a literal, I get the behaviour I'm looking for, but inlining a copy of my whole README.md is pretty inconvenient for making updates.
I tried:
#![doc = include!("README.md")]
but this gives an error:
error: unexpected token: `include`
--> src/lib.rs:3:10
|
3 | #![doc = include!("README.md")]
| ^^^^^^^
There is an unstable feature, external-doc, which enables this:
Example usage (nightly-only):
#![feature(external_doc)]
#![doc(include = "../README.md")]
Related
I have a module csv and am trying to use the external csv library (use csv::ReaderBuilder;). I am getting a conflict.
Minimal code that exhibits the error
mod csv {
use ::csv::ReaderBuilder;
}
Error message
--> src/csv.rs:4:5
|
4 | use csv::ReaderBuilder;
| ^^^ help: a similar path exists: `crate::csv`
|
= note: `use` statements changed in Rust 2018; read more at <https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html>
My question is how do I avoid such conflicts?
When creating a module, knowing the name of all modules that I may use via use seems un-reasonable. What am I doing wrong? I could name all my modules starting with my_, but this is ugly, and almost not the best solution.
Sorry if some of my terminology is wrong, I am new to rust.
You can disambiguate these where you use them. A leading crate path element indicates that the module belongs to the current crate. A leading empty path element indicates that the module belongs to the namespace root, much like a leading / character makes a filesystem path absolute.
use ::csv::Foo; // Uses Foo from the external csv crate
use crate::csv::Foo; // Uses Foo from the csv module of the current crate
It seems that I did not add the dependency to the Cargo.toml file.
On farther inspection, I see that the error message explains. However, I was confused by the help. It assumes that there is a syntax error in the use command.
In future I need to realise that the help part is a suggestion, not a description of the problem.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I'm using the latest stable version: rustc 1.46.0 (04488afe3 2020-08-24).
Rust Analyser needs the import:
use chrono::offset::TimeZone;
in order to accept the expression:
Utc.ymd(1970, 1, 1).and_hms_milli(0, 0, 0, 200)
(It highlights the .ymd as {unknown}.)
If I add the import, the compiler issues a warning:
Compiling foo v0.1.0 (/home/fadedbee/foo)
warning: unused import: `chrono::offset::TimeZone`
--> src/bar.rs:2:5
|
2 | use chrono::offset::TimeZone;
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
How can I make Rust Analyser (in vscode), and the compiler, both happy?
Update:
As rodrigo correctly deduced, the only uses of .ymd are within a #[cfg(test)] section.
This question already has an answer here:
Can't understand Rust module system
(1 answer)
Closed 2 years ago.
I am learning rust and am going through the book and have run into a question. Is it possible to access files within a folder? I am currently having issues with this.
Here is a project which demonstrates the issue: https://github.com/joemspalding/rust-stack-overflow-file-example/tree/master/src
In this project, I can successfully import functions from a different file, however, trying to access a file from a different folder is where I lose understanding syntactically. I feel I've tried nearly every combination of
mod foo;
mod foo::bar;
use foo;
use foo::bar;
Currently, running cargo run produces the following compile time error
Compiling my-project v0.1.0 (J:\Projects\rust\the_book\ch7\my-project)
error[E0432]: unresolved import `foo`
--> src\main.rs:1:5
|
1 | use foo::bar;
| ^^^ use of undeclared type or module `foo`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `my-project`.
To learn more, run the command again with --verbose.
I've been reading into this for hours and all of the resources I can find have great examples of reading code from a file on the same level, but not on reading code through folders.
Another common line I've seen is with the use of folder/mod.rs This seems unstylistic of rust after an update in 2018 and I'd like to avoid it if possible.
You must use mod.rs. It is the preferred option in rust 2018 and above. Module definitions aren't file paths and shouldn't be treated as such. Think of them more as C++ namespaces.
You could also choose to rename your mod.rs to match the name of the folder it is in (Ex: example_a/mod.rs -> example_a/example_a.rs). However I almost never this done and I find its much easier to navigate code with mod.rs.
If your mod.rs doesn't have any useful code, maybe you don't need a submodule.
A mod.rs should have code which relates to its sub modules. If it is only a couple lines long, you may want to skip adding the folder entirely since it doesn't sound like it has any purpose in your specific use case. This isn't like the empty __init__.py files of python 2.
This question already has an answer here:
How do you enable a Rust "crate feature"?
(1 answer)
Closed 3 years ago.
Managed to build and run some of the examples in https://github.com/rustwasm/wasm-bindgen/tree/master/examples
Then started with little prototype program for Dom manipulation, things works, until stuck on this.
Use
https://docs.rs/web-sys/0.3.35/web_sys/struct.HtmlButtonElement.html
lists pub struct HtmlButtonElement, similar to
https://docs.rs/web-sys/0.3.35/web_sys/struct.Element.html and
https://docs.rs/web-sys/0.3.35/web_sys/struct.HtmlElement.html
Having:
use web_sys::Element;
use web_sys::HtmlElement;
use web_sys::HtmlButtonElement;
Gives compile error:
error[E0432]: unresolved import `web_sys::HtmlButtonElement`
--> src/lib.rs:8:5
|
8 | use web_sys::HtmlButtonElement;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `HtmlButtonElement` in the root
While Element and HtmlElement are found in web_sys
What is the difference/missing for HtmlButtonElement? Does the no HtmlButtonElement in the root message give a clue?
Following the comment by #chpio. When adding HtmlButtonElement to features in Cargo.toml HtmlButtonElement is found when building.
This question already has answers here:
Use of # symbol in Node module names [duplicate]
(5 answers)
Closed 4 years ago.
With the release of material-ui version 1, I noticed they have added an # symbol to the front of the library name #material-ui/core. After digging into my node modules, I see that they aren't the only one - I have #babel and #types as well.
Is the # significant for some reason, or is it just for the purposes of clarity and avoiding conflicts with previous versions of the library?
# indicates that the package is a scoped package. It is a way of grouping similar projects under single scope. A scoped package can be published as private as well as public. For more info check out the following link npm-scope