Reenable linkchecker for books
In some senses, this is a revert of https://github.com/rust-lang/rust/pull/39633/commits/cacb3bc9c741a7d41a1085af850cd3ff852307f5#diff-b64563d143f859565c8357a28ef81101R212; we disabled linkchecker for the book because the links were added by JavaScript. Now, that's fixed upstream, and so we can re-enable the checker.
This also involves two other fixes: we have to check for `name`s as well as `id`s for links, and the linking algorithm of mdBook changed to the same as rustdoc's, so we change some links back.
~~~This isn't quite ready yet; it's [depending on a PR of mine to mdBook](https://github.com/azerupi/mdBook/pull/209). After that's released, this should be the last of these kinds of shenanigans~~~ 😄
This is good to go 😄
Rust Book: Generics: Resolving ambiguities
- Add a small section to generics.md to explain how ambiguities in type inference can be resolved using the `::<>` syntax.
- Add links from syntax-index.md and iterators.md.
- Minor edits to iterators.md and structs.md.
This reverts commit 7f1d1c6d9a.
The original commit was created because mdBook and rustdoc had
different generation algorithms for header links; now with
https://github.com/rust-lang/rust/pull/39966 , the algorithms
are the same. So let's undo this change.
... when I came across this problem, I said "eh, this isn't fun,
but it doesn't take that long." I probably should have just actually
taken the time to fix upstream, given that they were amenable. Oh
well!
- Add a small section to generics.md to explain how ambiguities in type
inference can be resolved using the ::<> syntax.
- Add links from syntax-index.md and iterators.md.
- Minor edits to iterators.md and structs.md.
Correct a typo in procedural macros chapter of the Book.
A simple and short correction for procedural macros chapter of the Rust Programming Language Book.
The use of a GNU C extension for bloc expressions is immaterial to the
actual problem with C macros that the section tries to show so don’t
use it and instead use a plain C way of writing the macro.
mdbook has a lot of optional dependencies that we don't want, so instead
of using it directly, we re-build rustbook to use mdbook as a library.
For convenience' sake, we keep the same CLI interface as mdbook; the
only difference is that it only accepts build and test subcommands,
rather than the full range.
Fix short hand struct doc
Don't want to discredit @hngiang effort on this issue.
I just want to lend a hand to fix this issue #38830, it is a very nice feature and is seemingly completed.
Fixes#39096
r? @steveklabnik
Update if-let.md
Calling if-let a combination of if and let is confusing, as some may be led to believe that it's a literal combination, instead of syntactic sugar added to the language as a convenience. What's there to stop someone from thinking if-let is just if and let together?
I do think this article does a good job of implying what's really going on; however, I was only able to notice this after I had begun to understand if/while-let statements, courtesy of the Rust IRC chat.
Basically, this article lacks the clarity and explicitness an inexperienced programmer like me needs in order to understand the contents fully. This is shown by my inability to understand the if-let concept from this page of the Book alone.
I think convenience, sugar, and (if-let != if + let) should all be made mention of in a clear, explicit manner. I lack confidence in my understanding of this issue, so I wrote just enough to hopefully get my thoughts across.
rustdoc: fix doctests with non-feature crate attrs
Fixes#38129.
The book says that any top-level crate attributes at the beginning of a doctest are moved outside the generated `fn main`, but it was only checking for `#![feature`, not `#![`.
These attributes previously caused warnings but were then ignored, so in theory this could change the behavior of doctests in the wild.
Extend Cell to work with non-Copy types
I'm not sure that I did this right but all of the tests pass.
I also had to move the `new()` function so that `Cell`s with non-`Copy` `T`s could be created. That wasn't in the RFC but I assume it needed to be done?
Improve doc cfg(test) and tests directory
Hi,
I was facing a problem with my code organisation. I was using a tests directory and i defined some `#[cfg(test)]` in my `src/`. But i was not able to use it in my `tests` folder.
```bash
.
├── Cargo.lock
├── Cargo.toml
├── src
│ ├── lib.rs
│ └── test.rs
└── tests
└── x.rs
```
> src/lib.rs
```rust
pub mod test;
fn tesst() {
assert!(test::t());
}
```
> src/test.rs
```rust
pub fn t() -> bool { true }
```
> test/x.rs
```rust
extern crate testt;
use testt::test;
fn tesst() {
assert!(test::t());
}
```
I was unable to compile using `cargo test`:
```bash
error[E0432]: unresolved import `testt::test`
--> tests/x.rs:3:5
|
3 | use testt::test;
| ^^^^^^^^^^^ no `test` in `testt`
```
If i remove the `tests` directory everything works fine. To use an utils module in your `tests` directory, you need to create a module in the directory (like `tests/utils.rs`). My `tests/x.rs` look like this now:
```rust
extern crate testt;
mod utils;
fn tesst() {
assert!(utils::t());
}
```
And my tree:
```bash
.
├── Cargo.lock
├── Cargo.toml
├── src
│ └── lib.rs
└── tests
├── utils.rs
└── x.rs
```
I think that thing must be documented in the book.
Ping:
- @badboy : Because he's the one who showed me the path
- @shahn : Because he helped me too to find the solution
Signed-off-by: Freyskeyd <simon.paitrault@iadvize.com>