Fix `unused_braces` lint suggestion when encountering attributes
This PR fixes the `unused_braces` lint suggestion when encountering attributes by not removing them in the suggestion.
Fixesrust-lang/rust#141549
Deduplicate dyn compatibility violations due to coercion
Don't unnecessarily emit dyn compatibility violations due to coercion to a non-dyn-compatible target type.
For us to even have that target type, we would have had to write `dyn Trait` somewhere in source, and that would have led to us *already* emitting a dyn compatibility violation when checking that user written type is WF.
r? oli-obk
Properly analyze captures from unsafe binders
We need to represent the unsafe binder unwrap as an adjustment in HIR. Pretty straightforward b/c we already represent it as a projection elem in MIR.
Fixes#141418Fixes#141417
r? oli-obk
Emit dummy open drop for unsafe binder
Fixesrust-lang/rust#141394
We can't taint the body in wfcheck when we have a `T: Copy` bound failure, so we end up binding MIR here. Emit a dummy open drop so that drop elaboration doesn't fail.
r? oli-obk
Avoid extra path trimming in method not found error
Method errors have an extra check that force trim paths whenever the normal string is longer than 10 characters, which can be quite unhelpful when multiple items have the same name (for example an `Error`).
A user reported this force trimming as being quite unhelpful when they had a method error where the precise path of the `Error` mattered.
The code uses `tcx.short_string` already to get the normal path, which tries to be clever around trimming paths if necessary, so there is no reason for this extra force trimming.
Method errors have an extra check that force trim paths whenever the
normal string is longer than 10 characters, which can be quite unhelpful
when multiple items have the same name (for example an `Error`).
A user reported this force trimming as being quite unhelpful when they
had a method error where the precise path of the `Error` mattered.
The code uses `tcx.short_string` already to get the normal path, which
tries to be clever around trimming paths if necessary, so there is no
reason for this extra force trimming.
Use the fn_span when emitting function calls for better debug info.
This especially improves the developer experience for long chains of function calls that span multiple lines, which is common with builder patterns, chains of iterator/future combinators, etc.
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: arm-android
r? `@jieyouxu`
Do not try to confirm non-dyn compatible method
See the comment I left in `compiler/rustc_hir_typeck/src/method/confirm.rs`.
If we have a receiver that does not deref to the `dyn Trait` we're assembling the method from, then we used to ICE, but that's something that is possible to encounter with arbitrary self types.
r? oli-obk
Fixes https://github.com/rust-lang/rust/issues/141419
Dont walk into unsafe binders when emiting error for non-structural type match
Fixes#141422.
The other two binder-having types are also special cased here, unsurprisingly.
r? oli-obk
Async drop poll shim for error dropee generates noop body
Fixes https://github.com/rust-lang/rust/issues/140930.
When dropee type for async drop poll shim is `ty::Error(_)`, the generated poll function will be noop body. To avoid ICE in `elaborate_drop`.
Defer evaluating type system constants when they use infers or params
Split out of #137972, the parts necessary for associated const equality and min generic const args to make progress and have correct semantics around when CTFE is invoked. According to a [previous perf run](https://perf.rust-lang.org/compare.html?start=93257e2d20809d82d1bc0fcc1942480d1a66d7cd&end=01b4cbf0f47c3f782330db88fa5ba199bba1f8a2&stat=instructions:u) of adding the new `const_arg_kind` query we should expect minor regressions here.
I think this is acceptable as we should be able to remove this query relatively soon once mgca is more complete as we'll then be able to implement GCE in terms of mgca and rip out `GCEConst` at which point it's trivial to determine what kind of anon const we're dealing with (either it has generics and is a repeat expr hack, or it doesnt and is a normal anon const).
This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters.
Fixes#133066Fixes#133199Fixes#136894Fixes#137813
r? compiler-errors
aarch64-softfloat: forbid enabling the neon target feature
This fixes https://github.com/rust-lang/rust/issues/134375 in a rather crude way, by making [the example](https://godbolt.org/z/r56xWo8nT) not build any more on aarch64-unknown-none-softfloat. That is a breaking change since the "neon" aarch64 target feature is stable, but this is justified as a soundness fix. Note that it's not "neon" which is problematic but "fp-armv8"; however, the two are tied together by rustc.
`-Ctarget-feature=+neon` still works, it just causes a warning (but one that we do hope to make a hard error eventually). Only `#[target_feature="neon"]` becomes a hard error with this PR.
More work on the LLVM side will be needed before we can let people use neon without impacting the ABI of float values (and, in particular, the ABI used by automatically inserted calls to libm functions, e.g. for int-to-float casts, which rustc has no control over).
Nominating for `@rust-lang/lang` since it is a breaking change. As-is this PR doesn't have a warning cycle; the hope is that the aarch64-unknown-none-softfloat target is sufficiently niche that there's no huge fallout and we can easily revert if it causes trouble. A warning cycle could be added but would need some dedicated rather hacky check in the target_feature attribute handling logic.
try-job: dist-various-1
This especially improves the developer experience for long chains
of function calls that span multiple lines, which is common with
builder patterns, chains of iterator/future combinators, etc.
Rollup of 7 pull requests
Successful merges:
- #135562 (Add ignore value suggestion in closure body)
- #139635 (Finalize repeat expr inference behaviour with inferred repeat counts)
- #139668 (Handle regions equivalent to 'static in non_local_bounds)
- #140218 (HIR ty lowering: Clean up & refactor the lowering of type-relative paths)
- #140435 (use uX::from instead of _ as uX in non - const contexts)
- #141130 (rustc_on_unimplemented cleanups)
- #141286 (Querify `coroutine_hidden_types`)
Failed merges:
- #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't allow `poly_select` in new solver
I added a `poly_select` call in #140519, but this causes an ICE since the new solver doesn't properly handle the "instantiate binder -> recanonicalize" step in the proof tree visitor.
While we could fix the select visitor to look at the next step in proof tree, it's not really necessary. Instead, let's enforce that all callees call the non-higher-ranked `select` function in the new solver.
Fixes https://github.com/rust-lang/rust/issues/141322
r? lcnr
Normalize aliases to correct kind of error term
Fixes#140642
When normalizing an alias to an error in the old solver, normalize to the same term kind as the alias being normalized instead of always to a type error.
r? lcnr
Fix `FnOnce` impl for `AsyncFn`/`AsyncFnMut` self-borrowing closures in new solver
This only affects closures that are "`AsyncFn`/`AsyncFnMut`" in their calling capability that are being called with the `FnOnce` trait.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/217
r? lcnr
HIR ty lowering: Clean up & refactor the lowering of type-relative paths
While rebasing #126651 I realized that HIR ty lowering could benefit from some *spring cleaning* now that it's been extended to handle RTN and mGCA paths.
More seriously, similar to my merged PR #118668 which unified the handling of all *associated item constraints* (assoc ty, const (ACE) & fn (RTN)), this PR (commit https://github.com/rust-lang/rust/pull/140218/commits/695fcf517d8864b4812225643ef8cfc036ba9f61) partially[^1] deduplicates the resolution code for all *type-relative paths* (assoc ty, const (mGCA) & fn (RTN)).
**Why**? DRY'ing that part of the code means PR #126651 will automatically support RTN paths like `Ty::AssocTy::assoc_fn(..)` and it also implies shared diagnostic code and thus better diagnostics for RTN.
---
The other commits represent cleanups, renamings, moves. More notably, I've renamed path lowering methods to be a lot more descriptive, so ones lowering `QPath(Resolved)` paths now have `_resolved_` in their name and ones lowering `QPath(TypeRelative)` paths now have `_type_relative_` in their name. This should make it stupidly obvious what their purpose is.
---
Best reviewed commit by commit. The changes are close to trivial but the diff might make it look hairier.
r? compiler-errors
[^1]: Sadly, I couldn't unify as much compared to the other PR without introducing unnecessary `unreachable!()`s or rendering the code otherwise illegible with flags and micro helper traits.
Handle regions equivalent to 'static in non_local_bounds
`non_local_bounds` would only find non local bounds that strictly bound a given region, but it's possible that a local region is equated to 'static when showing a type referencing a locally bound lifetime, such as `dyn Any + 'a` in the tests added, is well-formed. In this case we should return 'static.
closes#122704closes#139004
Finalize repeat expr inference behaviour with inferred repeat counts
I believe this should be the last change of how repeat exprs are handled before it's finished for `generic_arg_infer`. Assuming we don't wind up deciding to replace this all with a new predicate kind :)
This PR has three actual changes:
- Always defer the checks to end of typeck even when generic arg infer is not enabled (needs an FCP)
- Properly handle element exprs that are constants when the repeat count is inferred
- "Isolate" each repeat expr check so that inference constraints from `Copy` goals dont affect other repeat expr checks resulting in weird order-dependent inference
The commit history and tests should be relatively helpful for understanding this PR's impl.
r? compiler-errors
dont handle bool transmute
removes `transmute(u8) -> bool` suggestion due to ambiguity, leave it for clippy
elaboration on ambiguity in question:
`transmute::<u8, bool>(x)` will codegen to an `assume(u8 < 2)`;
`_ == 1` or `_ != 0` or `_ % 2 == 0` would remove that assumption
`match _ { x @ (0 | 1) => x == 1, _ => std::hint::unreachable_unchecked() }` is very verbose
`@rustbot` label L-unnecessary_transmutes
lower bodies' params to thir before the body's value
Two motivations for this:
- Lowering params first means errors from lowering the params are emitted before errors from lowering the body's expression. This comes up in [tests/ui/associated-consts/associated-const-type-parameter-pattern.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:thir-lower-params-before-body-expr?expand=1#diff-acac6ea10e991af0da91633e08b2739f9f9ca0c8f826401b6ba829914d0806f2), where both the params and expression encounter errors in translating consts to patterns. This change puts the errors in the order they appear in the source file.
- Guard patterns (#129967) contain expressions, so lowering params containing guard patterns may add more expressions to the THIR. However, there's a check for `-Zunpretty=thir-tree` that the final expression in the THIR corresponds to its value [(link)](c43786c9b7/compiler/rustc_mir_build/src/builder/mod.rs (L453-L455)); lowering params last would break this. As an alternative way to get guard patterns to work, I think the pretty-printer could use the expression returned by `thir_body` and the check could be removed or changed (#141357).
incorrectly prefer builtin `dyn` impls :3
This makes #57893 slightly more exploitable with the new solver. It's still strictly better than the old solver and the underlying unsoundness persists in the new one even without this preference.
Properly fixing #57893 is something we've been looking at more deeply recently and discussed at the [Types Meetup during the All-Hands](https://hackmd.io/rz-4ghMzTb2wXOkdLKHaHw#Dyn-traits). Whatever approach we'll end up deciding on will likely require a fairly long transition period and some significant further design work. This should not block `-Znext-solver`.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/183
r? `@compiler-errors` cc `@rust-lang/types`
