Matthias Krüger [Sat, 18 Dec 2021 09:26:35 +0000 (10:26 +0100)]
Rollup merge of #91439 - ecstatic-morse:const-cmp-trait-default-methods, r=oli-obk
Mark defaulted `PartialEq`/`PartialOrd` methods as const
WIthout it, `const` impls of these traits are unpleasant to write. I think this kind of change is allowed now. although it looks like it might require some Miri tweaks. Let's find out.
bors [Sat, 18 Dec 2021 07:20:50 +0000 (07:20 +0000)]
Auto merge of #92059 - matthiaskrgr:rollup-bainfyh, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #87901 (Fix suggestion of additional `pub` when using `pub pub fn ...`)
- #89090 (Lint bare traits in AstConv.)
- #91818 (Show the unused type for `unused_results` lint)
- #91910 (miri: lift restriction on extern types being the only field in a struct)
- #91928 (Constify (most) `Option` methods)
- #91975 (Move generator check earlier in inlining.)
- #92016 (builtin_macros: allow external consumers for AsmArgs parsing)
Matthias Krüger [Sat, 18 Dec 2021 07:16:31 +0000 (08:16 +0100)]
Rollup merge of #92016 - calebcartwright:expose-asm-args-parsing, r=Amanieu
builtin_macros: allow external consumers for AsmArgs parsing
As discussed in Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/parsing.20of.20AsmArgs.20for.20inline.20assembly), we need a function entry point that rustfmt can leverage from a pre-expansion context to get a more structured representation of the asm args without having to duplicate/maintain the token stream parsing
Matthias Krüger [Sat, 18 Dec 2021 07:16:30 +0000 (08:16 +0100)]
Rollup merge of #91975 - cjgillot:noinline-generator, r=jackh726
Move generator check earlier in inlining.
Inlining into generator may create references to other generators. For instance, inlining `Pin::<&mut from_generator::GenFuture<[generator1]>>::new_unchecked` into `generator2`. This cross reference can then create cycles when computing inlining for `generator1`.
In order to avoid this kind of surprises, we forbid all inlining into generators, and rely on LLVM to do the right thing. The existing `remove-zst-query-cycle` already ICEs in inline-mir mode, so we use it as test.
Matthias Krüger [Sat, 18 Dec 2021 07:16:27 +0000 (08:16 +0100)]
Rollup merge of #91818 - camelid:unused-result-type, r=jackh726
Show the unused type for `unused_results` lint
I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.
Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.
bors [Fri, 17 Dec 2021 22:12:34 +0000 (22:12 +0000)]
Auto merge of #89841 - cormacrelf:let-else-typed, r=nagisa
Implement let-else type annotations natively
Tracking issue: #87335
Fixes #89688, fixes #89807, edit: fixes #89960 as well
As explained in https://github.com/rust-lang/rust/issues/89688#issuecomment-940405082, the previous desugaring moved the let-else scrutinee into a dummy variable, which meant if you wanted to refer to it again in the else block, it had moved.
This introduces a new hir type, ~~`hir::LetExpr`~~ `hir::Let`, which takes over all the fields of `hir::ExprKind::Let(...)` and adds an optional type annotation. The `hir::Let` is then treated like a `hir::Local` when type checking a function body, specifically:
* `GatherLocalsVisitor` overrides a new `Visitor::visit_let_expr` and does pretty much exactly what it does for `visit_local`, assigning a local type to the `hir::Let` ~~(they could be deduplicated but they are right next to each other, so at least we know they're the same)~~
* It reuses the code in `check_decl_local` to typecheck the `hir::Let`, simply returning 'bool' for the expression type after doing that.
* ~~`FnCtxt::check_expr_let` passes this local type in to `demand_scrutinee_type`, and then imitates check_decl_local's pattern checking~~
* ~~`demand_scrutinee_type` (the blindest change for me, please give this extra scrutiny) uses this local type instead of of creating a new one~~
* ~~Just realised the `check_expr_with_needs` was passing NoExpectation further down, need to pass the type there too. And apparently this Expectation API already exists.~~
Some other misc notes:
* ~~Is the clippy code supposed to be autoformatted? I tried not to give huge diffs but maybe some rustfmt changes simply haven't hit it yet.~~
* in `rustc_ast_lowering/src/block.rs`, I noticed some existing `self.alias_attrs()` calls in `LoweringContext::lower_stmts` seem to be copying attributes from the lowered locals/etc to the statements. Is that right? I'm new at this, I don't know.
bors [Fri, 17 Dec 2021 19:17:29 +0000 (19:17 +0000)]
Auto merge of #91838 - scottmcm:array-slice-eq-via-arrays-not-slices, r=dtolnay
Do array-slice equality via array equality, rather than always via slices
~~Draft because it needs a rebase after #91766 eventually gets through bors.~~
This enables the optimizations from #85828 to be used for array-to-slice comparisons too, not just array-to-array.
For example, <https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=5f9ba69b3d5825a782f897c830d3a6aa>
```rust
pub fn demo(x: &[u8], y: [u8; 4]) -> bool {
*x == y
}
```
Currently writes the array to stack for no reason:
```nasm
sub rsp, 4
mov dword ptr [rsp], edx
cmp rsi, 4
jne .LBB0_1
mov eax, dword ptr [rdi]
cmp eax, dword ptr [rsp]
sete al
add rsp, 4
ret
.LBB0_1:
xor eax, eax
add rsp, 4
ret
```
Whereas with the change in this PR it just compares it directly:
```nasm
cmp rsi, 4
jne .LBB1_1
cmp dword ptr [rdi], edx
sete al
ret
bors [Fri, 17 Dec 2021 10:37:26 +0000 (10:37 +0000)]
Auto merge of #92023 - ehuss:update-cargo, r=ehuss
Update cargo
8 commits in a359ce16073401f28b84840da85b268aa3d37c88..fcef61230c3b6213b6b0d233a36ba4ebd1649ec3
2021-12-14 18:40:22 +0000 to 2021-12-17 02:30:38 +0000
- Minor docs change for `cargo test --help` (rust-lang/cargo#10210)
- Make clippy happy (rust-lang/cargo#10205)
- Enhance descriptions of issue templates (rust-lang/cargo#10202)
- Add workaround for sporadic kills when building on Macos (rust-lang/cargo#10196)
- Detect filesystem loop during walking the projects (rust-lang/cargo#10188)
- Error about not having any crates with documentation (rust-lang/cargo#10204)
- Don't document libs with doc=false (rust-lang/cargo#10201)
- Bumps up tar to 0.4.36 (rust-lang/cargo#10198)
bors [Thu, 16 Dec 2021 23:08:02 +0000 (23:08 +0000)]
Auto merge of #92003 - matthiaskrgr:rollup-obgv0rt, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #91172 (Warn when a `#[test]`-like built-in attribute macro is present multiple times.)
- #91796 (Fix since attribute for const_manually_drop feature)
- #91879 (Remove `in_band_lifetimes` from `rustc_borrowck`)
- #91947 (Add `io::Error::other`)
- #91967 (Pull in libdevstat on FreeBSD)
- #91987 (Add module documentation for rustdoc passes)
- #92001 (Fix default_method_body_is_const when used across crates)
bors [Thu, 16 Dec 2021 19:56:45 +0000 (19:56 +0000)]
Auto merge of #91616 - saethlin:sort_unchecked-sb-fix, r=Mark-Simulacrum
Fix #91306 by deriving all access from a single *mut T
Fixes #91306.
The previous code is invalid because the first argument to `copy_nonoverlapping` is invalidated by the mutable borrow taken out to construct the second argument.
I believe this patch fixes that, and this code should now pass Miri with `-Ztag-raw-pointers`, ~~but I'm currently stuck trying to run my reproducer with a this patched version of the standard library (alternatively, running Miri on the standard library tests itself would suffice).~~ Ralf walked me through this on Zulip.
I've also added fixes for 7 more problems other than those I reported. Most of them are easy to hit by calling sort_unstable on random arrays. I don't have reproducers for every change, but they seem pretty clear-cut to me. But I did only start learning stacked borrows 2 days ago so that might be a large dash of Dunning-Kruger.
Matthias Krüger [Thu, 16 Dec 2021 16:23:12 +0000 (17:23 +0100)]
Rollup merge of #91987 - jsha:docdocgoose, r=jyn514
Add module documentation for rustdoc passes
These are currently documented at https://rustc-dev-guide.rust-lang.org/rustdoc-internals.html#hot-potato but can easily go out of date. We'd like to document them in place and link to https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/passes/index.html
[Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/moving.20pass.20docs/near/265058351).
Matthias Krüger [Thu, 16 Dec 2021 16:23:10 +0000 (17:23 +0100)]
Rollup merge of #91947 - ibraheemdev:io-error-other, r=joshtriplett
Add `io::Error::other`
This PR adds a small utility constructor, `io::Error::other`, a shorthand for `io::Error::new(io::ErrorKind::Other, err)`, something I find myself writing often.
For some concrete stats, a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`:
```
Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3,898 results
Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2,186 results
```
Ben Kimock [Tue, 7 Dec 2021 01:44:02 +0000 (20:44 -0500)]
Fix SB problems in slice sorting
Most of these problems originate in use of get_unchecked_mut.
When calling ptr::copy_nonoverlapping, using get_unchecked_mut for both
arguments causes the borrow created to make the second pointer to invalid the
first.
The pairs of identical MaybeUninit::slice_as_mut_ptr calls similarly
invalidate each other.
There was also a similar borrow invalidation problem with the use of
slice::get_unchecked_mut to derive the pointer for the CopyOnDrop.
Matthias Krüger [Thu, 16 Dec 2021 09:12:46 +0000 (10:12 +0100)]
Rollup merge of #91972 - RalfJung:pref-align-of, r=Mark-Simulacrum
link to pref_align_of tracking issue
If we are not going to remove this intrinsic (https://github.com/rust-lang/rust/pull/90877), I think we should at least have a place to centralize discussion around it, so here we go. Intrinsics don't have their own separate features and usually we instead use the public method for tracking it, but this one does not have such a method... so the tracking issue is just a regular link. (And then we sue it for the const part as well.)
Matthias Krüger [Thu, 16 Dec 2021 09:12:43 +0000 (10:12 +0100)]
Rollup merge of #91951 - SparrowLii:master, r=Amanieu
update stdarch
2 commits in d219ad63c5075098fc224a57deb4852b9734327d..0716b22e902207efabe46879cbf28d0189ab7924
2021-12-9 23:50:37 +0000 to 2021-12-14 16:17:57 +0100
* Fix a bunch of typos ([Fix a bunch of typos stdarch#1267](https://github.com/rust-lang/stdarch/pull/1267))
* Stabilize armv8 neon instruction set on aarch64 ([Stabilize armv8 neon instruction set on aarch64 stdarch#1266](https://github.com/rust-lang/stdarch/pull/1266))
The update stabilizes armv8 neon instructions on aarch64. #90972
These are currently documented at
https://rustc-dev-guide.rust-lang.org/rustdoc-internals.html#hot-potato
but can easily go out of date. We'd like to document them in place and
link to
https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/passes/index.html
bors [Thu, 16 Dec 2021 02:21:30 +0000 (02:21 +0000)]
Auto merge of #89836 - pierwill:fix-85142-crate-hash, r=wesleywiser
Include rustc version in `rustc_span::StableCrateId`
`rustc_span::def_id::StableCrateId` is a hash of various data about a crate during compilation. This PR includes the version of `rustc` in the input when computing this hash. From a cursory reading of [RFC 2603](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html), this appears to be acceptable within that design.
In order to pass the `mir-opt` and `ui` test suites, this adds new [normalization for hashes and symbol names in `compiletest`](https://github.com/rust-lang/rust/pull/89836/files#diff-03a0567fa80ca04ed5a55f9ac5c711b4f84659be2d0ac4a984196d581c04f76b). These are enabled by default, but we might prefer it to be configurable.
In the UI tests, I had to truncate a significant amount of error annotations in v0 symbols (and maybe some legacy) in order to get the normalization to work correctly. (See https://github.com/rust-lang/rust/issues/90116.)
bors [Wed, 15 Dec 2021 10:46:43 +0000 (10:46 +0000)]
Auto merge of #7978 - smoelius:master, r=llogiq
Add `unnecessary_to_owned` lint
This PR adds a lint to check for unnecessary calls to `ToOwned::to_owned` and other similar functions (e.g., `Cow::into_owned`, `ToString::to_string`, etc.).
The lint checks for expressions of the form `&receiver.to_owned_like()` used in a position requiring type `&T` where one of the following is true:
* `receiver`'s type is `T` exactly
* `receiver`'s type implements `Deref<Target = T>`
* `receiver`'s type implements `AsRef<T>`
The lint additionally checks for expressions of the form `receiver.to_owned_like()` used as arguments of type `impl AsRef<T>`.
It would be nice if the lint could also check for expressions used as arguments to functions like the following:
```
fn foo<T: AsRef<str>>(x: T) { ... }
```
However, I couldn't figure out how to determine whether a function input type was instantiated from a parameter with a trait bound.
If someone could offer me some guidance, I would be happy to add such functionality.
Matthias Krüger [Wed, 15 Dec 2021 09:57:03 +0000 (10:57 +0100)]
Rollup merge of #91918 - fee1-dead:constification0-the-great-constification-begins, r=oli-obk
Constify `bool::then{,_some}`
Note on `~const Drop`: it has no effect when called from runtime functions, when called from const contexts, the trait system ensures that the type can be dropped in const contexts.
Matthias Krüger [Wed, 15 Dec 2021 09:57:02 +0000 (10:57 +0100)]
Rollup merge of #91916 - steffahn:fix-typos, r=dtolnay
Fix a bunch of typos
I hope that none of these files is not supposed to be modified.
FYI, I opened separate PRs for typos in submodules, in the respective repositories
* https://github.com/rust-lang/stdarch/pull/1267
* https://github.com/rust-lang/backtrace-rs/pull/455
Matthias Krüger [Wed, 15 Dec 2021 09:56:59 +0000 (10:56 +0100)]
Rollup merge of #91885 - LegionMammal978:less-inband-codegen_ssa, r=workingjubilee
Remove `in_band_lifetimes` from `rustc_codegen_ssa`
See #91867 for more information.
In `compiler/rustc_codegen_ssa/src/coverageinfo/map.rs`, there are several functions with an explicit `'a` lifetime but only a single `&'a self` parameter. These lifetimes should be redundant given lifetime elision, unless the existential `impl Iterator` has weird issues regarding that. Should the redundant lifetimes be removed?
This is my first try, I followed the instructions given. Fixed all the errors that were thrown while compiling.
Compiled with stage 0,1, and 2 all of them compiled successfully.
Matthias Krüger [Wed, 15 Dec 2021 07:36:20 +0000 (08:36 +0100)]
Rollup merge of #91479 - scottmcm:slice-as-simd, r=workingjubilee
Add `[T]::as_simd(_mut)`
SIMD-style optimizations are the most common use for `[T]::align_to(_mut)`, but that's `unsafe`. So these are *safe* wrappers around it, now that we have the `Simd` type available, to make it easier to use.
bors [Wed, 15 Dec 2021 06:34:00 +0000 (06:34 +0000)]
Auto merge of #91752 - yaahc:track-caller-result, r=cuviper
Readd track_caller to Result::from_residual
This is a followup on https://github.com/rust-lang/rust/issues/87401 in and an attempt to move the issue towards resolution.
As part of the overhaul of the Try trait we removed the ability for errors to grab location information during propagation via `?` with the builtin `std::result::Result`. The previously linked issue has a fair bit of discussion into the reasons for and against the usage of `#[track_caller]` on the `FromResidual` impl on `Result` that I will do my best to summarize.
---
### For
- https://github.com/rust-lang/rust/issues/87401#issuecomment-915053533: Difficulties with using non `std::result::Result` like types
- https://github.com/rust-lang/rust/issues/87401#issuecomment-978355102: Inconsistency with functionality provided for recoverable (Result) and non-recoverable errors (panic), where panic provides a location and Result does not, pushing some users towards using panic
### Against
- https://github.com/rust-lang/rust/issues/84277#issuecomment-885322833: concern that this will bloat callers that never use this data
---
Personally, I want to quantify the performance / bloat impact of re-adding this attribute, and fully evaluate the pros and cons before deciding if I need to switch `eyre` to have a custom `Result` type, which would also mean I need `try_trait_v2` to be stabilized, cc `@scottmcm.` If the performance impact is minor enough in the general case I think I would prefer that the default `Result` type has the ability to track location information for consistency with `panic` error reporting, and leave it to applications that need particularly high performance to handle the micro optimizations of introducing their own efficient custom Result type or matching manually.
Alternatively, I wonder if the performance penalty on code that doesn't use the location information on `FromResidual` could be mitigated via new optimizations.