Rollup of 7 pull requests
Successful merges:
- #91858 (pass -Wl,-z,origin to set DF_ORIGIN when using rpath)
- #91923 (Remove `in_band_lifetimes` from `rustc_query_impl`)
- #91925 (Remove `in_band_lifetimes` from `rustc_privacy`)
- #91977 (Clean up search code and unify function returned values)
- #92018 (Fix typo in "new region bound" suggestion)
- #92022 (Eliminate duplicate codes of expected_found_bool)
- #92032 (hir: Do not introduce dummy type names for `extern` blocks in def paths)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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.
Update stdlib to the 2021 edition
progress towards https://github.com/rust-lang/rust/issues/88638
I couldnt find a way to run the 2018 style panic tests against 2018 so I just deleted them, maybe theres a way to do it that I missed though?
Improve suggestion to change struct field to &mut
r? ``@estebank``
Now displays a proper underline style suggestion instead of including the code change inline with the message.
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.
r? ```@fee1-dead```
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`
