hir: Do not introduce dummy type names for `extern` blocks in def paths
Use a separate nameless `DefPathData` variant instead.
Extracted from https://github.com/rust-lang/rust/pull/91795.
Clean up search code and unify function returned values
This PR is a cleanup: there is no changes in the search results or in the UI.
Depending if it was "literal search" or not, it was either returning booleans or integers. It's pretty bad so instead it all returns integers.
Another thing I did was to move the add and checks into a `addIntoResults` function to simplify things.
Last thing: I removed a loop in the `sortResults` function and moved its code directly into the first loop.
All these changes are done to make #90630 much smaller.
r? `@jsha`
pass -Wl,-z,origin to set DF_ORIGIN when using rpath
DF_ORIGIN flag signifies that the object being loaded may make reference to the $ORIGIN substitution string.
Some implementations are just ignoring [DF_ORIGIN](http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#df_flags) and do [substitution](http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#substitution) for $ORIGIN if present (whatever DF_ORIGIN presence or not) like glibc. But some others mandate the present of DF_ORIGIN for the substitution (like OpenBSD).
Set the flag inconditionally if rpath is wanted.
One possible fallout is if the linker rejects `-z origin` option.
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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.
Split from #91743.
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.
Lint bare traits in AstConv.
Removing the lint from lowering allows to:
- make lowering querification easier;
- have the lint implementation in only one place.
r? `@estebank`
Fix suggestion of additional `pub` when using `pub pub fn ...`
Fix#87694.
Marked as draft to start with because I want to explore doing the same fix for `const const fn` and other repeated-but-valid keywords.
`@rustbot` label A-diagnostics D-invalid-suggestion T-compiler
Implement let-else type annotations natively
Tracking issue: #87335Fixes#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.
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
.LBB1_1:
xor eax, eax
ret
```
DF_ORIGIN flag signifies that the object being loaded may make reference to the $ORIGIN substitution string.
Some implementations are just ignoring DF_ORIGIN and do substitution for $ORIGIN if present (whatever DF_ORIGIN pr
Set the flag inconditionally if rpath is wanted.
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)
Implement normalize_erasing_regions queries in terms of 'try' version
Attempt to lessen performance regression caused by https://github.com/rust-lang/rust/pull/91255
r? `@jackh726`
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.
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
```
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.
