We already handle this case this way on the coherence side, and it matches the new solver's behaviour. While there is some breakage around type-alias-impl-trait (see new "type annotations needed" in tests/ui/type-alias-impl-trait/issue-84660-unsoundness.rs), no stable code breaks, and no new stable code is accepted.
Rewrite native thread-local storage
(part of #110897)
The current native thread-local storage implementation has become quite messy, uses indescriptive names and unnecessarily adds code to the macro expansion. This PR tries to fix that by using a new implementation that also allows more layout optimizations and potentially increases performance by eliminating unnecessary TLS accesses.
This does not change the recursive initialization behaviour I described in [this comment](https://github.com/rust-lang/rust/issues/110897#issuecomment-1525705682), so it should be a library-only change. Changing that behaviour should be quite easy now, however.
r? `@m-ou-se`
`@rustbot` label +T-libs
Rollup of 8 pull requests
Successful merges:
- #124297 (Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type)
- #124516 (Allow monomorphization time const eval failures if the cause is a type layout issue)
- #124976 (rustc: Use `tcx.used_crates(())` more)
- #125210 (Cleanup: Fix up some diagnostics)
- #125409 (Rename `FrameworkOnlyWindows` to `RawDylibOnlyWindows`)
- #125416 (Use correct param-env in `MissingCopyImplementations`)
- #125421 (Rewrite `core-no-oom-handling`, `issue-24445` and `issue-38237` `run-make` tests to new `rmake.rs` format)
- #125438 (Remove unneeded string conversion)
r? `@ghost`
`@rustbot` modify labels: rollup
Rewrite `core-no-oom-handling`, `issue-24445` and `issue-38237` `run-make` tests to new `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The test which is now called `non-pie-thread-local` has an unexplained "only-linux" flag. Could it be worth trying to remove it and changing the CI to test non-Linux platforms on it?
Use correct param-env in `MissingCopyImplementations`
We shouldn't assume the param-env is empty for this lint, since although we check the struct has no parameters, there still may be trivial where-clauses.
fixes#125394
Cleanup: Fix up some diagnostics
Several diagnostics contained their error code inside their primary message which is no bueno.
This PR moves them out of the message and turns them into structured error codes.
Also fixes another occurrence of `->` after a selector in a Fluent message which is not correct. I've fixed two other instances of this issue in #104345 (2022) but didn't update all instances as I've noted here: https://github.com/rust-lang/rust/pull/104345#issuecomment-1312705977 (“the future is now!”).
Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type
r? `@compiler-errors`
This accepts more code on stable. It is now possible to have match arms return a function item `foo` and a different function item `bar` in another, and that will constrain OpaqueTypeInDefiningScope to have the hidden type ConcreteType and make the type of the match arms a function pointer that matches the signature. So the following function will now compile, but on master it errors with a type mismatch on the second match arm
```rust
fn foo<T>(t: T) -> T {
t
}
fn bar<T>(t: T) -> T {
t
}
fn k() -> impl Sized {
fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F {
f
}
let x = match true {
true => {
let f = foo;
bind(k(), f)
}
false => bar::<()>,
};
todo!()
}
```
cc https://github.com/rust-lang/rust/issues/116652
This is very similar to https://github.com/rust-lang/rust/pull/123794, and with the same rationale:
> this is for consistency with `-Znext-solver`. the new solver does not have the concept of "non-defining use of opaque" right now and we would like to ideally keep it that way. Moving to `DefineOpaqueTypes::Yes` in more cases removes subtlety from the type system. Right now we have to be careful when relating `Opaque` with another type as the behavior changes depending on whether we later use the `Opaque` or its hidden type directly (even though they are equal), if that later use is with `DefineOpaqueTypes::No`*
Fix: infer type of async block with tail return expr
Fixes#17106
The `infer_async_block` method calls the `infer_block` method internally, which returns the never type without coercion when `tail_expr` is `None` and `ctx.diverges` is `Diverges::Always`.This is the reason for the bug in this issue.
https://github.com/rust-lang/rust-analyzer/blob/cfce2bb46da62950a8b70ddb0b2a12332da1b1e1/crates/hir-ty/src/infer/expr.rs#L1411-L1413
This PR solves the bug by adding a process to coerce after calling `infer_block` method.
This code passes all the tests, including tests I added for this isuue, however, I am not sure if this solution is right. I think that this solution is an ad hoc solution. So, I would appreciate to have your review.
I apologize if I'm off the mark, but `infer_async_block` method should be rewritten to share code with the process of infering type of `expr::Closure` instead of the `infer_block` method. That way it will be closer to the infer process of rustc.
handle {self} when removing unused imports
Fixes#17139
On master
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner::{self, X}$0;
fn f() {
let y = inner::Y();
}
}
```
becomes
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner:self;
fn f() {
let y = inner::Y();
}
}
```
with this fix it instead becomes
```
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner;
fn f() {
let y = inner::Y();
}
}
```
Oli Scherer