Override `StepBy::{try_fold, try_rfold}`
Previous PR: https://github.com/rust-lang/rust/pull/51435
The previous PR was closed in favor of https://github.com/rust-lang/rust/pull/51601, which was later reverted. I don't think these implementations will make it harder to specialize `StepBy<Range<_>>` later, so we should be able to land this without any consequences.
This should fix https://github.com/rust-lang/rust/issues/57517 – in my benchmarks `iter` and `iter.step_by(1)` now perform equally well, provided internal iteration is used.
Resolve attributes in several places
Resolve attributes for Arm, Field, FieldPat, GenericParam, Param, StructField and Variant.
This PR is based on @petrochenkov work located at 83fdb8d598.
Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0
Closes https://github.com/rust-lang/rust/issues/15287.
After stabilizing `#![feature(bind_by_move_pattern_guards)]`, you can now use bind-by-move bindings in patterns and take references to those bindings in `if` guards of `match` expressions. For example, the following now becomes legal:
```rust
fn main() {
let array: Box<[u8; 4]> = Box::new([1, 2, 3, 4]);
match array {
nums
// ---- `nums` is bound by move.
if nums.iter().sum::<u8>() == 10
// ^------ `.iter()` implicitly takes a reference to `nums`.
=> {
drop(nums);
// --------- Legal as `nums` was bound by move and so we have ownership.
}
_ => unreachable!(),
}
}
```
r? @matthewjasper
compiletest: disable -Aunused for run-pass tests
Disabled the flag, but that led to quite a bit of fall out -- I think most of it is benign but I've not investigated thoroughly.
r? @petrochenkov
Refactor the `MirPass for QualifyAndPromoteConstants`
This is an accumulation of drive-by commits while working on `Vec::new` as a stable `const fn`.
The PR is probably easiest read commit-by-commit.
r? @oli-obk
cc @eddyb @ecstatic-morse -- your two PRs https://github.com/rust-lang/rust/pull/63812 and https://github.com/rust-lang/rust/pull/63860 respectively will conflict with this a tiny bit but it should be trivial to reintegrate your changes atop of this.
Rollup of 4 pull requests
Successful merges:
- #62205 (Add Iterator comparison methods that take a comparison function)
- #64152 (Use backtrace formatting from the backtrace crate)
- #64265 (resolve: Mark more erroneous imports as used)
- #64267 (rustdoc: fix diagnostic with mixed code block styles)
Failed merges:
r? @ghost
rustdoc: fix diagnostic with mixed code block styles
This fixes a relatively obscure issue where the diagnostic (emitted [here](ef54f57c5b/src/librustdoc/passes/check_code_block_syntax.rs (L69))) would get confused since the "is_fenced" flag wasn't reset properly.
Add Iterator comparison methods that take a comparison function
This PR adds `Iterator::{cmp_by, partial_cmp_by, eq_by, ne_by, lt_by, le_by, gt_by, ge_by}`. We already have `Iterator::{cmp, partial_cmp, ...}` which are less general (but not any simpler) than the ones I'm proposing here.
I'm submitting this PR now because #61505 has been merged, so this change should not have a noticeable effect on the `Iterator` docs page size.
The diff is quite messy, here's what I changed:
- The logic of `cmp` / `partial_cmp` / `eq` is moved to `cmp_by` / `partial_cmp_by` / `eq_by` respectively, changing `x.cmp(&y)` to `cmp(&x, &y)` in the `cmp` method where `cmp` is the given comparison function (and similar for `partial_cmp_by` and `eq_by`).
- `ne_by` / `lt_by` / `le_by` / `gt_by` / `ge_by` are each implemented in terms of one of the three methods above.
- The existing comparison methods are each forwarded to their `_by` counterpart, passing one of `Ord::cmp` / `PartialOrd::partial_cmp` / `PartialEq::eq` as the comparison function.
The corresponding `_by_key` methods aren't included because they're not as fundamental as the `_by` methods and can easily be implemented in terms of them. Is that reasonable, or would adding the `_by_key` methods be desirable for the sake of completeness?
I didn't add any tests – I couldn't think of any that weren't already covered by our existing tests. Let me know if there's a particular test that would be useful to add.
Fix regex replacement in theme detection
Fixes#64061.
This is sadly a lot of bad luck: after making the changes and re-build the docs, I just forgot to force reload the page. Hence having the old (working) version with two replacements instead of the failing regex. Sorry again about that...
cc @fenhl
r? @Mark-Simulacrum
Rustdoc: formatting to buffers
This should be reviewed commit-by-commit.
I've not attempted to fully flesh out what the end state of this PR could look like yet as I wanted to get it up for some early feedback (I already think this has some wins, too, so we could land it as-is).
The primary idea with `Buffer` is that it internally tracks whether we're printing to HTML or text, and the goal is that eventually instead of branch on `fmt.alternate()` anywhere, we'd call a helper like `buf.nbsp()` which would either return ` ` or ` ` depending on the target we're printing to. Obviously, that's not included in this PR, in part because it was already getting quite big.
This means that callers can pass in a closure like
`|buf| some_function(..., &mut buf)` and pass in arbitrary arguments to
that function without complicating the trait definition. We also keep
the impl for str and String, since it's useful to be able to just pass
in "" or format!("{}"...) results in some cases.
This changes Print's definition to take self, instead of &self, because
otherwise FnOnce cannot be called directly. We could instead take FnMut
or even Fn, but that seems like it'd merely complicate matters -- most
of the time, the FnOnce does not constrain us at all anyway. If it does,
a custom Print impl for &'_ SomeStruct is not all that painful.
