Rollup of 7 pull requests
Successful merges:
- #92092 (Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison)
- #92388 (Fix a minor mistake in `String::try_reserve_exact` examples)
- #92442 (Add negative `impl` for `Ord`, `PartialOrd` on `LocalDefId`)
- #92483 (Stabilize `result_cloned` and `result_copied`)
- #92574 (Add RISC-V detection macro and more architecture instructions)
- #92575 (ast: Always keep a `NodeId` in `ast::Crate`)
- #92583 (⬆️ rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fixes#92266
In some `HashStable` impls, we use a cache to avoid re-computing
the same `Fingerprint` from the same structure (e.g. an `AdtDef`).
However, the `StableHashingContext` used can be configured to
perform hashing in different ways (e.g. skipping `Span`s). This
configuration information is not included in the cache key,
which will cause an incorrect `Fingerprint` to be used if
we hash the same structure with different `StableHashingContext`
settings.
To fix this, the configuration settings of `StableHashingContext`
are split out into a separate `HashingControls` struct. This
struct is used as part of the cache key, ensuring that our caches
always produce the correct result for the given settings.
With this in place, we now turn off `Span` hashing during the
entire process of computing the hash included in legacy symbols.
This current has no effect, but will matter when a future PR
starts hashing more `Span`s that we currently skip.
Add RISC-V detection macro and more architecture instructions
This pull request includes:
- Update `stdarch` dependency to include ratified RISC-V supervisor and hypervisor instruction intrinsics which is useful in Rust kernel development
- Add macro `is_riscv_feature_detected!`
- Modify impl of `core::hint::spin_loop` to comply with latest version of `core::arch`
After this update, users may now develop RISC-V kernels and user applications more freely.
r? `@Amanieu`
Fix a minor mistake in `String::try_reserve_exact` examples
The examples of `String::try_reserve_exact` didn't actually use `try_reserve_exact`, which was probably a minor mistake, and this PR fixed it.
Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison
I tried to run https://github.com/rust-lang/miri-test-libstd on `alloc` with `-Zmiri-track-raw-pointers`, and got a failure on the test `slice::panic_safe`. The test failure has nothing to do with panic safety, it's from how the test tests for panic safety.
I minimized the test failure into this very silly program:
```rust
use std::cell::Cell;
use std::cmp::Ordering;
#[derive(Clone)]
struct Evil(Cell<usize>);
fn main() {
let mut input = vec![Evil(Cell::new(0)); 3];
// Hits the bug pattern via CopyOnDrop in core
input.sort_unstable_by(|a, _b| {
a.0.set(0);
Ordering::Less
});
// Hits the bug pattern via InsertionHole in alloc
input.sort_by(|_a, b| {
b.0.set(0);
Ordering::Less
});
}
```
To fix this, I'm just removing the mutability/uniqueness where it wasn't required.
Extract init_env_logger to crate
I've been doing some work on rustc_ast_pretty using an out-of-tree main.rs and Cargo.toml with the following:
```toml
[dependencies]
rustc_ast = { path = "../rust/compiler/rustc_ast" }
rustc_ast_pretty = { path = "../rust/compiler/rustc_ast_pretty" }
rustc_span = { path = "../rust/compiler/rustc_span" }
```
Rustc_ast_pretty helpfully uses `tracing::debug!` but I found that in order to enable the debug output, my test crate must depend on rustc_driver which is an enormously bigger dependency than what I have been using so far, and slows down iteration time because an enormous dependency tree between rustc_ast and rustc_driver must now be rebuilt after every ast change.
I pulled out the tracing initialization to a new minimal rustc_log crate so that projects depending on the other rustc crates, like rustc_ast_pretty, can access the `debug!` messages in them without building all the rest of rustc.
Set font size proportional to user's font size
According to MDN (https://developer.mozilla.org/en-US/docs/Web/CSS/font-size),
> To maximize accessibility, it is generally best to use values that are relative to the user's default font size.
> Defining font sizes in px is not accessible, because the user cannot change the font size in some browsers.
Note that changing font size (in browser or OS settings) is distinct from the zoom functionality triggered with Ctrl/Cmd-+. Zoom
functionality increases the size of everything on the page, effectively applying a multiplier to all pixel sizes. Font size changes apply to just text.
For relative font sizes, we could use `em`, as we do in several places already. However that has a problem of "compounding" (see MDN article for details). The compounding problem is nicely solved by `rem`, which make font sizes relative to the root element, not the parent element.
Since we were using a hodge-podge of pixel sizes, em, rem, and percentage sizes before, this change switches everything to rem, while keeping the same size relative to our old default of 16px.
16px is still the default on most browsers, for users that haven't set a larger or smaller font size.
Part of #59845. Note: this will conflict with #92404. We should merge that first (once it's done) and I'll resolve the merge conflicts.
r? `@GuillaumeGomez`
Demo: https://rustdoc.crud.net/jsha/font-size-access/std/string/struct.String.html
Do not hash leading zero bytes of i64 numbers in Sip128 hasher
I was poking into the stable hasher, trying to improve its performance by compressing the number of hashed bytes. First I was experimenting with LEB128, but it was painful to implement because of the many assumptions that the SipHasher makes, so I tried something simpler - just ignoring leading zero bytes. For example, if an 8-byte integer can fit into a 4-byte integer, I will just hash the four bytes.
I wonder if this could produce any hashing ambiguity. Originally I thought so, but then I struggled to find any counter-example where this could cause different values to have the same hash. I'd be glad for any examples that could be broken by this (there are some ways of mitigating it if that would be the case). It could happen if you had e.g. 2x `u8` vs 1x `u16` hashed after one another in two different runs, but that can also happen now, without this "trick". And with collections, it should be fine, because the length is included in their hash.
I gathered some statistics for common values used in the `clap` benchmark. I observed that especially `i64` often had very low values, so I started with that type, let's see what perf does on CI.
There are some tradeoffs that we can try:
1) What types to use this optimization for? `u64`, `u32`, `u16`? Locally it was a slight loss for `u64`, I noticed that its values are often quite large.
2) What byte sizes to check? E.g. we can only distinguish between `u64`/`u32` or `u64`/`u8` instead of `u64`/`u32`/`u16`/`u8` to reduce branching (with `i64` it seemed to be better to go all the way down to `u8` locally though).
(The macro was introduced because I expect that I will be trying out this "trick" for different types).
Can you please schedule a perf. run? Thanks.
r? `@the8472`
Better detect when a field can be moved from in `while_let_on_iterator`
fixes#8113
changelog: Better detect when a field can be moved from in `while_let_on_iterator`
Ignore flaky `panic-short-backtrace-windows-x86_64.rs` test for now
Mitigates (but does not fix) #92000.
It has been causing a lot of spurious test failures recently that slow
down the bors queue.
Update cargo
10 commits in fcef61230c3b6213b6b0d233a36ba4ebd1649ec3..358e79fe56fe374649275ca7aebaafd57ade0e8d
2021-12-17 02:30:38 +0000 to 2022-01-04 18:39:45 +0000
- Make rmeta_required no longer depend on whether timing is enabled (rust-lang/cargo#10254)
- The first version of pull request template (rust-lang/cargo#10218)
- Stabilize the `strip` profile option, now that rustc has stable `-C strip` (rust-lang/cargo#10088)
- Update docs for windows ssh-agent. (rust-lang/cargo#10248)
- Fix typo: substract -> subtract (rust-lang/cargo#10244)
- timings: Fix tick mark alignment (rust-lang/cargo#10239)
- Remove unused lifetimes (rust-lang/cargo#10238)
- Make levenshtein distance case insensitive. (rust-lang/cargo#10224)
- [docs] Adds basic CI yaml for GitHub Actions (rust-lang/cargo#10212)
- Add function for parsing already-read manifest (rust-lang/cargo#10209)
Fix `type_repetition_in_bounds`
fixes#7360fixes#8162fixes#8056
changelog: Check for full equality in `type_repetition_in_bounds` rather than just equal hashes
Remove in_macro from clippy_utils
changelog: none
Previously done in #7897 but reverted in #8170. I'd like to keep `in_macro` out of utils because if a span is from expansion in any way (desugaring or macro), we should not proceed without understanding the nature of the expansion IMO.
r? `@llogiq`
Rollup of 7 pull requests
Successful merges:
- #91587 (core::ops::unsize: improve docs for DispatchFromDyn)
- #91907 (Allow `_` as the length of array types and repeat expressions)
- #92515 (RustWrapper: adapt for an LLVM API change)
- #92516 (Do not use deprecated -Zsymbol-mangling-version in bootstrap)
- #92530 (Move `contains` method of Option and Result lower in docs)
- #92546 (Update books)
- #92551 (rename StackPopClean::None to Root)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
New macro utils
changelog: none
Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.
Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`
Fixes#7843 by not parsing every node of macro implementations, at least the major offenders.
I probably want to get rid of `is_expn_of` at some point.
changelog: none
Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.
Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`
Fixes#7843 by not parsing every node of macro implementations, at least the major offenders.
I probably want to get rid of `is_expn_of` at some point.
rename StackPopClean::None to Root
With https://github.com/rust-lang/rust/pull/90102, `StackPopClean::None` is now only used for the "root" frame of the stack, so adjust its name accordingly and add an assertion.
r? `@oli-obk`
Update books
## reference
3 commits in 06f9e61931bcf58b91dfe6c924057e42ce273ee1..f8ba2f12df60ee19b96de24ae5b73af3de8a446b
2021-12-17 07:31:40 -0800 to 2022-01-03 11:02:08 -0800
- Switch the default edition for examples to 2021 (rust-lang/reference#1125)
- Clarify behavior of x87 FP registers in inline assembly (rust-lang/reference#1126)
- Add inline assembly to the reference (rust-lang/reference#1105)
## book
36 commits in 8a0bb3c96e71927b80fa2286d7a5a5f2547c6aa4..d3740fb7aad0ea4a80ae20f64dee3a8cfc0c5c3c
2021-12-22 20:54:27 -0500 to 2022-01-03 21:46:04 -0500
- Add a concrete example of an optional value. Fixesrust-lang/book#2848.
- match isn't really an operator. Fixesrust-lang/book#2859
- Edits to edits of chapter 6
- Make fixes recommended by shellcheck
- Use shellcheck
- SIGH fix all the typos that were missed while spellcheck was broken
- SIGH add all the words to the dictionary that were missed while spellcheck was broken
- Remove test_harness from the dictionary
- sigh, the xkcd sandwich one
- Install aspell in CI
- set -eu in all bash scripts
- typo: assignement -> assignment
- Fix quotes
- Snapshot of ch12 for nostarch
- Use 'static lifetime earlier because that's more correct. Fixesrust-lang/book#2864.
- Add does_not_compile annotation to intermediate steps that don't compile
- Sidestep who provides output streams. Fixesrust-lang/book#2933.
- Remove note about primitive obsession. Fixesrust-lang/book#2863.
- Remove sentence encouraging writing tests on your own. Fixesrust-lang/book#2223.
- Bump mdBook version to 0.4.14 in workflow main.yml
- Past tense make better sense
- Past tense makes better sense
- Update the edition in all the listings' Cargo.toml
- Update the book to either say 2021 edition or not talk about editions
- Remove most of the 2018 edition text from the title page. Fixesrust-lang/book#2852.
- Fix word wrapping
- Emphasize return type is mandatory
- fix title capitalization
- Further edits to mention of --include-ignored, propagate to src
- feat: mention `cargo test -- --include-ignored`
- wording: get rid of "to from"
- interchanged position of `binary` and `library`
- Fix wrong word typo
- Further edits in rust-analyzer text
- appendix-04 IDE integration: Replaced rls by rust-analyzer
- Update link to Italian translation. Connects to rust-lang/book#2484.
## rustc-dev-guide
3 commits in 9bf0028b557798ddd07a6f652e4d0c635d3d6620..875464457c4104686faf667f47848aa7b0f0a744
2021-12-20 21:53:57 +0900 to 2021-12-28 22:17:49 -0600
- Update link to moved section (rust-lang/rustc-dev-guide#1282)
- Fix link in contributing.md (rust-lang/rustc-dev-guide#1280)
- Streamline "Getting Started" (rust-lang/rustc-dev-guide#1279)
Move `contains` method of Option and Result lower in docs
Follow-up to #92444 trying to get the `Option` and `Result` rustdocs in better shape.
This addresses the request in https://github.com/rust-lang/rust/issues/62358#issuecomment-645676285. The `contains` methods are previously too high up in the docs on both `Option` and `Result` — stuff like `ok` and `map` and `and_then` should all be featured higher than `contains`. All of those are more ubiquitously useful than `contains`.
