Add `f16` and `f128` as simd types in LLVM
`@sayantn` is working on adding SIMD for `f16` and hitting the `FloatingPointVector` error. This should fix it and unblock adding support for `simd_fma` and `simd_fabs` in stdarch.
Avoid follow-up errors and ICEs after missing lifetime errors on data structures
Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result.
Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place.
I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists).
fixes#124262fixes#124083fixes#125155fixes#125888fixes#125992fixes#126666fixes#126648fixes#127268fixes#127266fixes#127304
Implement simple, unstable lint to suggest turning closure-of-async-block into async-closure
We want to eventually suggest people to turn `|| async {}` to `async || {}`. This begins doing that. It's a pretty rudimentary lint, but I wanted to get something down so I wouldn't lose the code.
Tracking:
* #62290
Make `visit_clobber`'s impl safe
This was originally introduced in #58061 but I didn't see any perf discussion about it, so let's see what perf says.
r? `@nnethercote`
instantiate higher ranked goals in candidate selection again
This reverts #119820 as that PR has a significant impact and breaks code which *feels like it should work*. The impact ended up being larger than we expected during the FCP and we've ended up with some ideas for how we can work around this issue in the next solver. This has been discussed in the previous high bandwidth t-types meeting: https://rust-lang.zulipchat.com/#narrow/stream/326132-t-types.2Fmeetings/topic/2024-07-09.20high.20bandwidth.20meeting.
We'll therefore keep this inconsistency between the two solvers for now and will have to deal with it before stabilizating the use of the new solver outside of coherence: https://github.com/rust-lang/trait-system-refactor-initiative/issues/120.
fixes#125194 after a beta-backport.
The pattern which is more widely used than expected and feels like it should work, especially without deep knowledge of the type system is
```rust
trait Trait<'a> {}
impl<'a, T> Trait<'a> for T {}
fn trait_bound<T: for<'a> Trait<'a>>() {}
// A function with a where-bound which is more restrictive than the impl.
fn function1<T: Trait<'static>>() {
// stable: ok
// with #119820: error as we prefer the where-bound over the impl
// with this PR: back to ok
trait_bound::<T>();
}
```
r? `@rust-lang/types`
Update `f16`/`f128` FIXMEs that needed `(NEG_)INFINITY`
Just a small fix to the pattern matching tests now that we can. Also contains a small unrelated comment tweak.
More trait error reworking
More work on #127492, specifically those sub-bullets under "Move trait error reporting to `error_reporting::traits`". Stacked on top of #127493.
This does introduce new `TypeErrCtxt.*Ext` traits, but those will be deleted soon. Splitting this work into bite-sized pieces is the only way that it's gonna be feasible to both author and review ❤️
r? lcnr
Automatically taint when reporting errors from ItemCtxt
This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.
based on https://github.com/rust-lang/rust/pull/127357
r? `@fmease`
[Coverage][MCDC] Group mcdc tests and fix panic when generating mcdc code for inlined expressions.
### Changes
1. Group all mcdc tests to one directory.
2. Since mcdc instruments different mappings for boolean expressions with normal branch coverage as #125766 introduces, it would be better also trace branch coverage results in mcdc tests.
3. So far rustc does not call `CoverageInfoBuilderMethods::init_coverage` for inlined functions. As a result, it could panic if it tries to instrument mcdc statements for inlined functions due to uninitialized cond bitmaps. We can reproduce this issue by current nightly rustc and [the test](https://github.com/rust-lang/rust/pull/127234/files#diff-c81af6bf4869aa42f5c7334e3e86344475de362f673f54ce439ec75fcb5ac3e5) with flag `--release`. This patch fixes it.
This is adding a migration lint for the current (in the 2021 edition and previous)
to move expr to expr_2021 from expr
Co-Developed-by: Eric Holk
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Fix regression in the MIR lowering of or-patterns
In https://github.com/rust-lang/rust/pull/126553 I made a silly indexing mistake and regressed the MIR lowering of or-patterns. This fixes it.
r? `@compiler-errors` because I'd like this to be merged quickly 🙏
Consolidate region error reporting in `rustc_infer`
More work on https://github.com/rust-lang/rust/issues/127492. Separate but important step, since I'm gonna likely pull everything else here into another module.
I don't think I'm confident whether `nice_region_error` should be a submodule of the new `rustc_infer::infer::error_reporting::region` module, so I left it alone for now.
r? lcnr
Move trait selection error reporting to its own top-level module
This effectively moves `rustc_trait_selection::traits::error_reporting` to `rustc_trait_selection::error_reporting::traits`. There are only a couple of actual changes to the code, like moving the `pretty_impl_header` fn out of the specialization module for privacy reasons.
This is quite pointless on its own, but having `error_reporting` as a top-level module in `rustc_trait_selection` is very important to make sure we have a meaningful file structure for when we move **type** error reporting (and region error reporting, with which it's incredibly entangled currently) into `rustc_trait_selection`. I've opened a tracking issue here: #127492
r? lcnr
Add Natvis visualiser and debuginfo tests for `f16`
To render `f16`s in debuggers on MSVC targets, this PR changes the compiler to output `f16`s as `struct f16 { bits: u16 }`, and includes a Natvis visualiser that manually converts the `f16`'s bits to a `float` which is can then be displayed by debuggers. `gdb`, `lldb` and `cdb` tests are also included for `f16` .
`f16`/`f128` MSVC debug info issue: #121837
Tracking issue: #116909
Infer async closure signature from (old-style) two-part `Fn` + `Future` bounds
When an async closure is passed to a function that has a "two-part" `Fn` and `Future` trait bound, like:
```rust
use std::future::Future;
fn not_exactly_an_async_closure(_f: F)
where
F: FnOnce(String) -> Fut,
Fut: Future<Output = ()>,
{}
```
The we want to be able to extract the signature to guide inference in the async closure, like:
```rust
not_exactly_an_async_closure(async |string| {
for x in string.split('\n') { ... }
//~^ We need to know that the type of `string` is `String` to call methods on it.
})
```
Closure signature inference will see two bounds: `<?F as FnOnce<Args>>::Output = ?Fut`, `<?Fut as Future>::Output = String`. We need to extract the signature by looking through both projections.
### Why?
I expect the ecosystem's move onto `async Fn` trait bounds (which are not affected by this PR, and already do signature inference fine) to be slow. In the mean time, I don't see major overhead to supporting this "old–style" of trait bounds that were used to model async closures.
r? oli-obk
Fixes#127468Fixes#127425
