Use the 64b inner:monotonize() implementation not the 128b one for aarch64
aarch64 prior to v8.4 (FEAT_LSE2) doesn't have an instruction that guarantees
untorn 128b reads except for completing a 128b load/store exclusive pair
(ldxp/stxp) or compare-and-swap (casp) successfully. The requirement to
complete a 128b read+write atomic is actually more expensive and more unfair
than the previous implementation of monotonize() which used a Mutex on aarch64,
especially at large core counts. For aarch64 switch to the 64b atomic
implementation which is about 13x faster for a benchmark that involves many
calls to Instant::now().
Rollup of 15 pull requests
Successful merges:
- #87993 (Stabilize try_reserve)
- #88090 (Perform type inference in range pattern)
- #88780 (Added abs_diff for integer types.)
- #89270 (path.push() should work as expected on windows verbatim paths)
- #89413 (Correctly handle supertraits for min_specialization)
- #89456 (Update to the final LLVM 13.0.0 release)
- #89466 (Fix bug with query modifier parsing)
- #89473 (Fix extra `non_snake_case` warning for shorthand field bindings)
- #89474 (rustdoc: Improve doctest pass's name and module's name)
- #89478 (Fixed numerus of error message)
- #89480 (Add test for issue 89118.)
- #89487 (Try to recover from a `=>` -> `=` or `->` typo in a match arm)
- #89494 (Deny `where` clauses on `auto` traits)
- #89511 (⬆️ rust-analyzer)
- #89536 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fixed numerus of error message
When there are redundant trait requirements and these are hidden, a message is generated by the following code snippet:
`format!("{} redundant requirements hidden", count)`
But if there is only a single hidden requirement, it will still print this message in plural instead of singular.
Fix extra `non_snake_case` warning for shorthand field bindings
Fixes#89469. The problem is the innermost `if` condition here:
d14731cb3c/compiler/rustc_lint/src/nonstandard_style.rs (L435-L452)
This code runs for every `PatKind::Binding`, so if a struct has multiple fields, say A and B, and both are bound in a pattern using shorthands, the call to `self.check_snake_case()` will indeed be skipped in the `check_pat()` call for `A`; but when `check_pat()` is called for `B`, the loop will still iterate over `A`, and `field.ident (= A) != ident (= B)` will be true. I have fixed this by only looking at non-shorthand bindings, and only the binding that `check_pat()` was actually called for.
Fix bug with query modifier parsing
The previous macro_rules! parsers failed when an additional modifier was added
with ambiguity errors. The error is pretty unclear as to what exactly the cause
here is, but this change simplifies the argument parsing code such that the
error is avoided.
Extracted from other work, and somewhat duplicates 0358edeb5 from #85830, but
this approach seems a little simpler to me. Not technically currently necessary but seems
like a good cleanup.
Correctly handle supertraits for min_specialization
Supertraits of specialization markers could circumvent checks for
min_specialization. Elaborating predicates prevents this.
r? ````@nikomatsakis````
path.push() should work as expected on windows verbatim paths
On Windows, std::fs::canonicalize() returns an so-called UNC path. UNC paths differ with regular paths because:
- This type of path can much longer than a non-UNC path (32k vs 260 characters).
- The prefix for a UNC path is ``Component::Prefix(Prefix::DiskVerbatim(..)))``
- No `/` is allowed
- No `.` is allowed
- No `..` is allowed
Rust has poor handling of such paths. If you join a UNC path with a path with any of the above, then this will not work.
I've implemented a new method `fn join_fold()` which joins paths and also removes any `.` and `..` from it, and replaces `/` with `\` on Windows. Using this function it is possible to use UNC paths without issue. In addition, this function is useful on Linux too; paths can be appended without having to call `canonicalize()` to remove the `.` and `..`.
This PR needs test cases, which can I add. I hope this will a start of a discussion.
The old JavaScript didn't work. It filled the browser console
with "e.previousElementSibling not defined" errors, because
it didn't account for the example-wrap div that a newer version
of rustdoc added.
Additionally, it had copied versions of utility functions that
had been optimized in rustdoc main.js. This version updates those.
Stabilize `const_panic`
Closes#51999
FCP completed in #89006
```@rustbot``` label +A-const-eval +A-const-fn +T-lang
cc ```@oli-obk``` for review (not `r?`'ing as not on lang team)
Fix ICE with buffered lint referring to AST node deleted by everybody_loops
Fixes#87308. Note the following comment:
08759c691e/compiler/rustc_lint/src/early.rs (L415-L417)
As it turns out, this is not _always_ a bug, because `-Zunpretty=everybody_loops` causes a lot of AST nodes to be deleted, and thus some buffered lints will refer to non-existent node ids. To fix this, my changes simply ignore buffered lints if `-Zunpretty=everybody_loops` is enabled, which, from my understanding, shouldn't be a big issue because it only affects pretty-printing. Of course, a more elegant solution would only ignore buffered lints that actually point at deleted node ids, but I haven't figured out an easy way of achieving this.
For the concrete example in #87308, the buffered lint is created [here](08759c691e/compiler/rustc_expand/src/mbe/macro_rules.rs (L145-L151)) with the `lint_node_id` from [here](08759c691e/compiler/rustc_expand/src/mbe/macro_rules.rs (L319)), i.e. it points at the macro _expansion_, which then gets deleted by `ReplaceBodyWithLoop` [here](08759c691e/compiler/rustc_interface/src/passes.rs (L377)).
Consistently use 'supertrait'.
A subset of places referred to 'super-trait', so this changes them
to all use 'supertrait'. This matches 'supertype' and some other
usages. An exception is 'auto-trait' which is consistently used
in that manner.
Improve wording of `map_or_else` docs
Changes doc text to refer to the "default" parameter as the "default"
function.
Previously, the doc text referred to the "f" parameter as the "default" function; and the "default" parameter as the "fallback" function.
Fix an ICE caused by type mismatch errors being ignored
This PR fixes#87771. It turns out that the check on `compiler/rustc_typeck/src/check/demand.rs:148` leads to the ICE. I removed it because the early return in [`check_expr_assign`](dec7fc3ced/compiler/rustc_typeck/src/check/expr.rs (L928)) already prevents unnecessary error messages from the call to `check_expr_coercable_to_type`.
implement advance_(back_)_by on more iterators
Add more efficient, non-default implementations for `feature(iter_advance_by)` (#77404) on more iterators and adapters.
This PR only contains implementations where skipping over items doesn't elide any observable side-effects such as user-provided closures or `clone()` functions. I'll put those in a separate PR.
[aarch64] add target feature outline-atomics
Enable outline-atomics by default as enabled in clang by the following commit
https://reviews.llvm.org/rGc5e7e649d537067dec7111f3de1430d0fc8a4d11
Performance improves by several orders of magnitude when using the LSE instructions
instead of the ARMv8.0 compatible load/store exclusive instructions.
Tested on Graviton2 aarch64-linux with
x.py build && x.py install && x.py test
Add lint `equatable_if_let`
This is my attempt for #1716. There is a major false positive, which is people may implement `PartialEq` in a different way. It is unactionable at the moment so I put it into `nursery`.
There is a trait `StructuralPartialEq` for solving this problem which is promising but it has several problems currently:
* Integers and tuples doesn't implement it.
* Some types wrongly implement it, like `Option<T>` when `T` doesn't implement it.
I consider them bugs and against the propose of `StructuralPartialEq`. When they become fixed, this lint can become a useful lint with a single line change.
changelog: New lint: [`equatable_if_let`]
