Migrate `cdylib-dylib-linkage` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
~~Those sysroot tests are always fun. I'm getting local errors that don't make a lot of sense about my own sysroot not existing, so I am trying this in CI to see what happens.~~
~~EDIT: I am getting the same error here. The strange thing is, when I try to navigate to `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib` on my personal computer, the directory does exist, but the error message is that the directory does not.~~
EDIT 2: The sysroot path just needed to be trimmed!
Please try:
// try-job: x86_64-msvc // passed previously
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
try-job: i686-msvc
try-job: aarch64-apple
On short error format, append primary span label to message
The `error-format=short` output only displays the path, error code and main error message all in the same line. We now add the primary span label as well after the error message, to provide more context.
The `error-format=short` output only displays the path, error code and
main error message all in the same line. We now add the primary span label
as well after the error message, to provide more context.
Tweak type inference for `const` operands in inline asm
Previously these would be treated like integer literals and default to `i32` if a type could not be determined. To allow for forward-compatibility with `str` constants in the future, this PR changes type inference to use an unbound type variable instead.
The actual type checking is deferred until after typeck where we still ensure that the final type for the `const` operand is an integer type.
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Rustc of course already WF-checked the field types at the definition
site, but for error tainting of consts to work properly, there needs to
be an error emitted at the use site. Previously, with no use-site error,
we proceeded with CTFE and ran into ICEs since we are running code with
type errors.
Emitting use-site errors also brings struct-like constructors more in
line with fn-like constructors since they already emit use-site errors
for WF issues.
Note that the test output is currently *incorrect*. We should be
emitting an error at the use site too, not just at the definition. This
is partly for UI reasons, but mainly to fix a related ICE where a const
generic body is not tainted with an error since no usage error is
reported.
interpret: move nullary-op evaluation into operator.rs
We call it an operator, so we might as well treat it like one. :)
Also use more consistent naming for the "evaluate intrinsic" functions. "emulate" is really the wrong term, this *is* a genuine implementation of the intrinsic semantics after all.
Use `ParamEnv::reveal_all` in CFI
I left a huge comment for why this ICEs in the test I committed.
`typeid_for_instance` should only be called on monomorphic instances during codegen, and we should just be using `ParamEnv::reveal_all()` rather than the param-env of the instance itself. I added an assertion to ensure that we only do this for fully substituted instances (this may break with polymorphization, but I kinda don't care lol).
Fixes#114160
cc `@rcvalle`
Enforce supertrait outlives obligations hold when confirming impl
**TL;DR:** We elaborate super-predicates and apply any outlives obligations when proving an impl holds to fix a mismatch between implied bounds.
Bugs in implied bounds (and implied well-formedness) occur whenever there is a mismatch between the assumptions that some code can assume to hold, and the obligations that a caller/user of that code must prove. If the former is stronger than the latter, then unsoundness occurs.
Take a look at the example unsoundness:
```rust
use std::fmt::Display;
trait Static: 'static {}
impl<T> Static for &'static T {}
fn foo<S: Display>(x: S) -> Box<dyn Display>
where
&'static S: Static,
{
Box::new(x)
}
fn main() {
let s = foo(&String::from("blah blah blah"));
println!("{}", s);
}
```
This specific example occurs because we elaborate obligations in `fn foo`:
* `&'static S: Static`
* `&'static S: 'static` <- super predicate
* `S: 'static` <- elaborating outlives bounds
However, when calling `foo`, we only need to prove the direct set of where clauses. So at the call site for some substitution `S = &'not_static str`, that means only proving `&'static &'not_static str: Static`. To prove this, we apply the impl, which itself holds trivially since it has no where clauses.
This is the mismatch -- `foo` is allowed to assume that `S: 'static` via elaborating supertraits, but callers of `foo` never need to prove that `S: 'static`.
There are several approaches to fixing this, all of which have problems due to current limitations in our type system:
1. proving the elaborated set of predicates always - This leads to issues since we don't have coinductive trait semantics, so we easily hit new cycles.
* This would fix our issue, since callers of `foo` would have to both prove `&'static &'not_static str: Static` and its elaborated bounds, which would surface the problematic `'not_static: 'static` outlives obligation.
* However, proving supertraits when proving impls leads to inductive cycles which can't be fixed until we get coinductive trait semantics.
2. Proving that an impl header is WF when applying that impl:
* This would fix our issue, since when we try to prove `&'static &'not_static str: Static`, we'd need to prove `WF(&'static &'not_static str)`, which would surface the problematic `'not_static: 'static` outlives obligation.
* However, this leads to issues since we don't have higher-ranked implied bounds. This breaks things when trying to apply impls to higher-ranked trait goals.
To get around these limitations, we apply a subset of (1.), which is to elaborate the supertrait obligations of the impl but filter only the (region/type) outlives out of that set, since those can never participate in an inductive cycle. This is likely not sufficient to fix a pathological example of this issue, but it does clearly fill in a major gap that we're currently overlooking.
This can also result in 'unintended' errors due to missing implied-bounds on binders. We did not encounter this in the crater run and don't expect people to rely on this code in practice:
```rust
trait Outlives<'b>: 'b {}
impl<'b, T> Outlives<'b> for &'b T {}
fn foo<'b>()
where
// This bound will break due to this PR as we end up proving
// `&'b &'!a (): 'b` without the implied `'!a: 'b`
// bound.
for<'a> &'b &'a (): Outlives<'b>,
{}
```
Fixes#98117
---
Crater: https://github.com/rust-lang/rust/pull/124336#issuecomment-2209165320
Triaged: https://github.com/rust-lang/rust/pull/124336#issuecomment-2236321325
All of the fallout is due to generic const exprs, and can be ignored.
Migrate `reproducible-build-2` and `stable-symbol-names` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Needs try-jobs.
try-job: x86_64-msvc
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: i686-msvc
try-job: x86_64-mingw
Rollup of 8 pull requests
Successful merges:
- #128026 (std:🧵 available_parallelism implementation for vxWorks proposal.)
- #128471 (rustdoc: Fix handling of `Self` type in search index and refactor its representation)
- #128607 (Use `object` in `run-make/symbols-visibility`)
- #128609 (Remove unnecessary constants from flt2dec dragon)
- #128611 (run-make: Remove cygpath)
- #128619 (Correct the const stabilization of `<[T]>::last_chunk`)
- #128630 (docs(resolve): more explain about `target`)
- #128660 (tests: more crashes)
r? `@ghost`
`@rustbot` modify labels: rollup
Use `object` in `run-make/symbols-visibility`
This is another case where we can simply use a rust library instead of wrangling nm.
try-job: x86_64-msvc
try-job: i686-msvc
try-job: test-various
Do not fire unhandled attribute assertion on multi-segment `AttributeType::Normal` attributes with builtin attribute as first segment
### The Problem
In #128581 I introduced an assertion to check that all builtin attributes are actually checked via
`CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes.
Unfortunately, the assertion had correctness problems as revealed in #128622.
The match on attribute path segments looked like
```rs,ignore
// Normal handler
[sym::should_panic] => /* check is implemented */
// Fallback handler
[name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) {
// checked below
Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
Some(_) => {
if !name.as_str().starts_with("rustc_") {
span_bug!(
attr.span,
"builtin attribute {name:?} not handled by `CheckAttrVisitor`"
)
}
}
None => (),
}
```
However, it failed to account for edge cases such as an attribute whose:
1. path segments *starts* with a segment matching the name of a builtin attribute such as `should_panic`, and
2. the first segment's symbol does not start with `rustc_`, and
3. the matched builtin attribute is also of `AttributeType::Normal` attribute type upon registration with the builtin attribute map.
These conditions when all satisfied cause the span bug to be issued for e.g.
`#[should_panic::skip]` because the `[sym::should_panic]` arm is not matched (since it's
`[sym::should_panic, sym::skip]`).
### Proposed Solution
This PR tries to remedy that by adjusting all normal/specific handlers to not match exactly on a single segment, but instead match a prefix segment.
i.e.
```rs,ignore
// Normal handler, notice the `, ..` rest pattern
[sym::should_panic, ..] => /* check is implemented */
// Fallback handler
[name, ..] => match BUILTIN_ATTRIBUTE_MAP.get(name) {
// checked below
Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {}
Some(_) => {
if !name.as_str().starts_with("rustc_") {
span_bug!(
attr.span,
"builtin attribute {name:?} not handled by `CheckAttrVisitor`"
)
}
}
None => (),
}
```
### Review Remarks
This PR contains 2 commits:
1. The first commit adds a regression test. This will ICE without the `CheckAttrVisitor` changes.
2. The second commit adjusts `CheckAttrVisitor` assertion logic. Once this commit is applied, the test should no longer ICE and produce the expected bless stderr.
Fixes#128622.
r? ``@nnethercote`` (since you reviewed #128581)
turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`
`````@rust-lang/types````` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error.
However, turns out that outright removing it right now would lead to [tons of crater regressions](https://github.com/rust-lang/rust/pull/127655#issuecomment-2228285460), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this.
Fixes https://github.com/rust-lang/rust/issues/27336 by removing the feature gate (so there's no way to silence the lint even on nightly)
CC https://github.com/rust-lang/rust/issues/36887
Move the standard library to a separate workspace
This ensures that the Cargo.lock packaged for it in the rust-src component is up-to-date, allowing rust-analyzer to run cargo metadata on the standard library even when the rust-src component is stored in a read-only location as is necessary for loading crates.io dependencies of the standard library.
This also simplifies tidy's license check for runtime dependencies as it can now look at all entries in library/Cargo.lock without having to filter for just the dependencies of runtime crates. In addition this allows removing an exception in check_runtime_license_exceptions that was necessary due to the compiler enabling a feature on the object crate which pulls in a dependency not allowed for the standard library.
While cargo workspaces normally enable dependencies of multiple targets to be reused, for the standard library we do not want this reusing to prevent conflicts between dependencies of the sysroot and of tools that are built using this sysroot. For this reason we already use an unstable cargo feature to ensure that any dependencies which would otherwise be shared get a different -Cmetadata argument as well as using separate build dirs.
This doesn't change the situation around vendoring. We already have several cargo workspaces that need to be vendored. Adding another one doesn't change much.
There are also no cargo profiles that are shared between the root workspace and the library workspace anyway, so it doesn't add any extra work when changing cargo profiles.
Rollup of 7 pull requests
Successful merges:
- #128305 (improve error message when `global_asm!` uses `asm!` operands)
- #128526 (time.rs: remove "Basic usage text")
- #128531 (Miri: add a flag to do recursive validity checking)
- #128578 (rustdoc: Cleanup `CacheBuilder` code for building search index)
- #128589 (allow setting `link-shared` and `static-libstdcpp` with CI LLVM)
- #128615 (rustdoc: make the hover trail for doc anchors a bit bigger)
- #128620 (Update rinja version to 0.3.0)
r? `@ghost`
`@rustbot` modify labels: rollup
improve error message when `global_asm!` uses `asm!` operands
follow-up to https://github.com/rust-lang/rust/pull/128207
what was
```
error: expected expression, found keyword `in`
--> src/lib.rs:1:31
|
1 | core::arch::global_asm!("{}", in(reg));
| ^^ expected expression
```
becomes
```
error: the `in` operand cannot be used with `global_asm!`
--> $DIR/parse-error.rs:150:19
|
LL | global_asm!("{}", in(reg));
| ^^ the `in` operand is not meaningful for global-scoped inline assembly, remove it
```
the span of the error is just the keyword, which means that we can't create a machine-applicable suggestion here. The alternative would be to attempt to parse the full operand, but then if there are syntax errors in the operand those would be presented to the user, even though the parser already knows that the output won't be valid. Also that would require more complexity in the parser.
So I think this is a nice improvement at very low cost.
Migrate `print-target-list` to `rmake` and `print-calling-convention` to ui-test
Part of #121876.
r? `@jieyouxu`
try-job: x86_64-gnu-llvm-18
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-apple
try-job: i686-mingw
try-job: x86_64-msvc
Update run-make/used to use `any_symbol_contains`
This makes it so we don't need `nm` or `llvm-nm`.
I also tested that `BAR` is removed. I'm not sure if this is wanted though.
Assert that all attributes are actually checked via `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes
``@oli-obk's`` #128444 with unreachable case removed to avoid that PR bitrotting away.
Based on #128402.
This PR will make adding a new attribute ICE on any use of that attribute unless it gets a handler added in `rustc_passes::CheckAttrVisitor`.
r? ``@nnethercote`` (since you were the reviewer of the original PR)
Implement `UncheckedIterator` directly for `RepeatN`
This just pulls the code out of `next` into `next_unchecked`, rather than making the `Some` and `unwrap_unchecked`ing it.
And while I was touching it, I added a codegen test that `array::repeat` for something that's just `Clone`, not `Copy`, still ends up optimizing to the same thing as `[x; n]`: <https://rust.godbolt.org/z/YY3a5ajMW>.
Simplify match based on the cast result of `IntToInt`
Continue to complete #124150. The condition in #120614 is wrong, e.g. `-1i8` cannot be converted to `255i16`. I've rethought the issue and simplified the conditional judgment for a more straightforward approach. The new approach is to check **if the case value after the `IntToInt` conversion equals the target value**.
In different types, `IntToInt` uses different casting methods. This rule is as follows:
- `i8`/`u8` to `i8`/`u8`: do nothing.
- `i8` to `i16`/`u16`: sign extension.
- `u8` to `i16`/`u16`: zero extension.
- `i16`/`u16` to `i8`/`u8`: truncate to the target size.
The previous error was a mix of zext and sext.
r? mir-opt
Revert recent changes to dead code analysis
This is a revert to recent changes to dead code analysis, namely:
* efdf219 Rollup merge of #128104 - mu001999-contrib:fix/128053, r=petrochenkov
* a70dc297a8 Rollup merge of #127017 - mu001999-contrib:dead/enhance, r=pnkfelix
* 31fe9628cf Rollup merge of #127107 - mu001999-contrib:dead/enhance-2, r=pnkfelix
* 2724aeaaeb Rollup merge of #126618 - mu001999-contrib:dead/enhance, r=pnkfelix
* 977c5fd419 Rollup merge of #126315 - mu001999-contrib:fix/126289, r=petrochenkov
* 13314df21b Rollup merge of #125572 - mu001999-contrib:dead/enhance, r=pnkfelix
There is an additional change stacked on top, which suppresses false-negatives that were masked by this work. I believe the functions that are touched in that code are legitimately unused functions and the types are not reachable since this `AnonPipe` type is not publically reachable -- please correct me if I'm wrong cc `@NobodyXu` who added these in ##127153.
Some of these reverts (#126315 and #126618) are only included because it makes the revert apply cleanly, and I think these changes were only done to fix follow-ups from the other PRs?
I apologize for the size of the PR and the churn that it has on the codebase (and for reverting `@mu001999's` work here), but I'm putting this PR up because I am concerned that we're making ad-hoc changes to fix bugs that are fallout of these PRs, and I'd like to see these changes reimplemented in a way that's more separable from the existing dead code pass. I am happy to review any code to reapply these changes in a more separable way.
cc `@mu001999`
r? `@pnkfelix`
Fixes#128272Fixes#126169
nested aux-build in tests/rustdoc/ tests
* Fixes bug that prevented using nested aux-build in `tests/rustdoc/` tests. Before, `fn document` and the auxiliary builder disagreed about where to find the nested aux-build source file (`auxiliary/auxiliary/aux.rs` vs `auxiliary/aux.rs`), preventing them from building. Picked the latter in line with other builders in compiletest.
* Adds `//@ doc-flags` header, which forwards flags to rustdoc and not rustc.
* Adds `//@ unique-doc-out-dir` header, which sets the --out-dir for the rustdoc invocation to a unique directory: `<root out dir>/docs/<test name>/doc`
* Changes working directory of the rustdoc invocation to the root out directory (common among all aux-builds). Prior art: exec_compiled_test in runtest.rs
* Adds tests that use nested aux builds and new headers
These changes provide useful capabilities for writing rustdoc tests on their own. They are also needed to test the implementation for the [mergable-rustdoc-cross-crate-info](https://github.com/rust-lang/rfcs/pull/3662) RFC.
try-job: x86_64-msvc
Added SHA512, SM3, SM4 target-features and `sha512_sm_x86` feature gate
This is an effort towards #126624. This adds support for these 3 target-features and introduces the feature flag `sha512_sm_x86`, which would gate these target-features and the yet-to-be-implemented detection and intrinsics in stdarch.
Migrate `cross-lang-lto-clang` and `cross-lang-lto-pgo-smoketest` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This has the same problem outlined by #126180, where the tests do not actually run as no test-running CI enviroment has `RUSTBUILD_FORCE_CLANG_BASED_TESTS` set.
However, I still find it interesting to turn the Makefiles into the rmake format until the Clang issue is fixed.
This should technically be tested on MSVC... if MSVC actually ran Clang tests.
try-job: x86_64-gnu-debug
Migrate `link-cfg` and `rustdoc-default-output` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
try-job: i686-msvc
Migrate `cross-lang-lto` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: i686-mingw
try-job: x86_64-mingw
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
Rollup of 6 pull requests
Successful merges:
- #126818 (Better handle suggestions for the already present code and fix some suggestions)
- #128436 (Update sysinfo version to 0.31.2)
- #128453 (raw_eq: using it on bytes with provenance is not UB (outside const-eval))
- #128491 ([`macro_metavar_expr_concat`] Dogfooding)
- #128494 (MIR required_consts, mentioned_items: ensure we do not forget to fill these lists)
- #128521 (rustdoc: Remove dead opaque_tys rendering logic)
r? `@ghost`
`@rustbot` modify labels: rollup
raw_eq: using it on bytes with provenance is not UB (outside const-eval)
The current behavior of raw_eq violates provenance monotonicity. See https://github.com/rust-lang/rust/pull/124921 for an explanation of provenance monotonicity. It is violated in raw_eq because comparing bytes without provenance is well-defined, but adding provenance makes the operation UB.
So remove the no-provenance requirement from raw_eq. However, the requirement stays in-place for compile-time invocations of raw_eq, that indeed cannot deal with provenance.
Cc `@rust-lang/opsem`
Better handle suggestions for the already present code and fix some suggestions
When a suggestion part is for code that is already present, skip it. If all the suggestion parts for a suggestion are for code that is already there, do not emit the suggestion.
Fix two suggestions that treat `span_suggestion` as if it were `span_help`.
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> $DIR/E0283.rs:30:21
|
LL | fn create() -> u32;
| ------------------- `Coroutine::create` defined here
...
LL | let cont: u32 = Coroutine::create();
| ^^^^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation
|
LL | let cont: u32 = <Impl as Coroutine>::create();
| ++++++++ +
LL | let cont: u32 = <AnotherImpl as Coroutine>::create();
| +++++++++++++++ +
```
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.
Fix clippy lint suggestion incorrectly treated as `span_help`.
interpret: on a signed deref check, mention the right pointer in the error
When a negative offset (like `ptr.offset(-10)`) goes out-of-bounds, we currently show an error saying that we expect the *resulting* pointer to be inbounds for 10 bytes. That's confusing, so this PR makes it so that instead we say that we expect the *original* pointer `ptr` to have 10 bytes *to the left*.
I also realized I can simplify the pointer arithmetic logic and handling of "staying inbounds of a target `usize`" quite a bit; the second commit does that.
More unsafe attr verification
This code denies unsafe on attributes such as `#[test]` and `#[ignore]`, while also changing the `MetaItem` parsing so `unsafe` in args like `#[allow(unsafe(dead_code))]` is not accidentally allowed.
Tracking:
- https://github.com/rust-lang/rust/issues/123757
Finish blessing `coverage/mcdc` tests after LLVM 19 upgrade
Context: https://github.com/rust-lang/rust/pull/127513#issuecomment-2260887708
These changes aren't needed for Rust CI, because after the LLVM 19 upgrade we have no jobs that run these tests in `coverage-run` mode against LLVM 18. But they might help external builds.
The longer-term plan is to completely drop (unstable) MC/DC support on LLVM 18, as part of getting it working on LLVM 19 in #126733.
cc `@cuviper`
Emit an error if `#[optimize]` is applied to an incompatible item
#54882
The RFC specifies that this should emit a lint. I used the same allow logic as the `coverage` attribute (also allowing modules and impl blocks) - this should possibly be changed depending on if it's decided to allow 'propogation' of the attribute.
Migrate `symbol-visibility` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Pretty scary!
- The expected number of symbols on each check has been changed slightly to reflect the differences between `llvm_readobj` and `nm`, as I think the former will print hidden symbols once and visible symbols twice, while the latter will only print visible symbols.
- The original test ran the same exact checks on `cdylib` twice, for seemingly no reason. I have removed it.
- This may be possible to optimize some more? `llvm_readobj` could get called only once for each library type, and the regex could avoid being created repeatedly. I am not sure if these kinds of considerations are important for a `run-make` test.
Demands a Windows try-job.
try-job: x86_64-mingw
Rollup of 7 pull requests
Successful merges:
- #123813 (Add `REDUNDANT_IMPORTS` lint for new redundant import detection)
- #126697 ([RFC] mbe: consider the `_` in 2024 an expression)
- #127159 (match lowering: Hide `Candidate` from outside the lowering algorithm)
- #128244 (Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks)
- #128431 (Add myself as VxWorks target maintainer for reference)
- #128438 (Add special-case for [T, 0] in dropck_outlives)
- #128457 (Fix docs for OnceLock::get_mut_or_init)
r? `@ghost`
`@rustbot` modify labels: rollup
derive(SmartPointer): require pointee to be maybe sized
cc ``@Darksonn``
So `#[pointee]` has to be `?Sized` in order for deriving `SmartPointer` to be meaningful.
cc ``@compiler-errors`` for suggestions in #127681
Properly mark loop as diverging if it has no breaks
Due to specifics about the desugaring of the `.await` operator, HIR typeck doesn't recognize that `.await`ing an `impl Future<Output = !>` will diverge in the same way as calling a `fn() -> !`.
This is because the await operator desugars to approximately:
```rust
loop {
match future.poll(...) {
Poll::Ready(x) => break x,
Poll::Pending => {}
}
}
```
We know that the value of `x` is `!`, however since `break` is a coercion site, we coerce `!` to some `?0` (the type of the loop expression). Then since the type of the `loop {...}` expression is `?0`, we will not detect the loop as diverging like we do with other expressions that evaluate to `!`:
0b5eb7ba7b/compiler/rustc_hir_typeck/src/expr.rs (L240-L243)
We can technically fix this in two ways:
1. Make coercion of loop exprs more eagerly result in a type of `!` when the only break expressions have type `!`.
2. Make loops understand that all of that if they have only diverging break values, then the loop diverges as well.
(1.) likely has negative effects on inference, and seems like a weird special case to drill into coercion. However, it turns out that (2.) is very easy to implement, we already record whether a loop has any break expressions, and when we do so, we actually skip over any break expressions with diverging values!:
0b5eb7ba7b/compiler/rustc_hir_typeck/src/expr.rs (L713-L716)
Thus, we can consider the loop as diverging if we see that it has no breaks, which is the change implemented in this PR.
This is not usually a problem in regular code for two reasons:
1. In regular code, we already mark `break diverging()` as unreachable if `diverging()` is unreachable. We don't do this for `.await`, since we suppress unreachable errors within `.await` (#64930). Un-suppressing this code will result in spurious unreachable expression errors pointing to internal await machinery.
3. In loops that truly have no breaks (e.g. `loop {}`), we already evaluate the type of the loop to `!`, so this special case is kinda moot. This only affects loops that have `break`s with values of type `!`.
Thus, this seems like a change that may affect more code than just `.await`, but it likely does not in meaningful ways; if it does, it's certainly correct to apply.
Fixes#128434
Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks
Also remove a heck of a lot of weird hacks in `suggest_cloning` that I don't think we should have around.
I know this regresses tests, but I don't believe most of these suggestions were accurate, b/c:
1. They either produced type errors (e.g. turning `&x` into `x.clone()`)
2. They don't fix the issue
3. They fix the issue ostensibly, but introduce logic errors (e.g. cloning a `&mut Option<T>` to then `Option::take` out...)
Most of the suggestions are still wrong, but they're not particularly *less* wrong IMO.
Stacked on top of #128241, which is an "obviously worth landing" subset of this PR.
r? estebank
match lowering: Hide `Candidate` from outside the lowering algorithm
The internals of `Candidate` are tricky and a source of confusion. This PR makes it so we don't expose `Candidate`s outside the lowering algorithm. Now:
- false edges are handled in `lower_match_tree`;
- `lower_match_tree` takes a list of patterns as input;
- `lower_match_tree` returns a flat datastructure that contains only the necessary information.
r? ```@matthewjasper```
Add `REDUNDANT_IMPORTS` lint for new redundant import detection
Defaults to Allow for now. Stacked on #123744 to avoid merge conflict, but much easier to review all as one.
r? petrochenkov
Accelerate GVN a little
This PR addresses a few inefficiencies I've seen in callgrind profiles.
Commits are independent.
Only the first commit introduces a change in behaviour: we stop substituting some constant pointers. But we keep propagating their contents that have no provenance, so we don't lose much.
r? `@saethlin`
