#20075 introduced a bug where unmarked code fences weren't considered as doctests. This PR fixes the logic.
---
This passed `check-stage1-rustdoc`, and I manually checked that:
``` rust
//! ```
//! println!("Hello")
//! ```
//!
//! ``` rust
//! println!("Hello")
//! ```
//!
//! ``` sh
//! println!("Hello")
//! ```
//!
//! ``` ignore
//! println!("Hello")
//! ```
```
Generated:
``` rust
running 3 tests
test _2 ... ignored
test _0 ... ok
test _1 ... ok
```
I'd love to add that as a test, but I have no idea how to do that with our testing infrastructure. If anyone knows how, do let me know!
r? @alexcrichton
@seanmonstar feedback?
Add support for all variants of ast::WherePredicate in clean/mod.rs. Fixes#20048, but will need modification when EqualityPredicates are fully implemented in #20041.
... really this time `:)`
I went for the simpler fix after all since it turned out to become a bit too complicated to extract the current iteration value from its containing `Option` with the different memory layouts it can have. It's also what we already do for match bindings.
I also extended the new test case to include the "simple identifier" case.
Fixes#20127, fixes#19732
We render HRTB and the unboxed closure trait sugar (the so-called
"parenthesized" notation) where appropriate. Also address the new
`for` syntax on the old closures.
According to [RFC 344][], methods that return `&[u8]` should have names ending in `bytes`. Though `include_bin!` is a macro not a method, it seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning when it is used.
[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md
[breaking-change]
`check::autoderef()` returns a `ty_err` when it fails to infer the type. `probe::probe()` should respect this failure and fail together to prevent further corruption.
Fixes#19692.
Fixes#19583.
Fixes#19297.
The previous behaviour of using the smallest type possible caused LLVM
to treat padding too conservatively, causing poor codegen. This commit
changes the behaviour to use an alignment-sized integer as the
discriminant. This keeps types the same size, but helps LLVM understand
the data structure a little better, resulting in better codegen.
Adds support for all variants of ast::WherePredicate in clean/mod.rs. Fixes#20048, but will need modification when EqualityPredicates are fully implemented in #20041.
Rename `FPCategory` to `FpCategory` and `Fp* to `*` in order to adhere to the
naming convention
This is a [breaking-change].
Existing code like this:
```
use std::num::{FPCategory, FPNaN};
```
should be adjusted to this:
```
use std::num::FpCategory as Fp
```
In the following code you can use the constants `Fp::Nan`, `Fp::Normal`, etc.
According to [RFC 344][], methods that return `&[u8]` should have names
ending in `bytes`. Though `include_bin!` is a macro not a method, it
seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning
when it is used.
[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md
[breaking-change]
The previous behaviour of using the smallest type possible caused LLVM
to treat padding too conservatively, causing poor codegen. This commit
changes the behaviour to use an type-alignment-sized integer as the
discriminant. This keeps types the same size, but helps LLVM understand
the data structure a little better, resulting in better codegen.
RFC 248? I think you meant RFC 438.
There ain’t an RFC 248, while 438 looks to be what is being referred to:
https://github.com/rust-lang/rfcs/blob/master/text/0438-precedence-of-plus.md
--------------
Chis Morgan has a pretty important documentation fix in #19385 and he hasn't responded in a while to that pull request so I rebased it for him
Closes#19385
Part of #19253
I would have removed this public reexport in #19842, but #19812 hadn't merged (and snapshotted) at the time
In #19407, I changed the codebase to stop utilizing this reexport
[breaking-change]
This is an updated version of #19711. The merge and subsequent rebase on that branch were more trouble than they were worth, so I am just resubmitting the relevant change here.
If this PR is accepted, then #19711 can be closed.
/cc @Gankro
