Rollup of 9 pull requests
Successful merges:
- #113568 (Fix spurious test failure with `panic=abort`)
- #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`)
- #114485 (Add trait decls to SMIR)
- #114495 (Set max_atomic_width for AVR to 16)
- #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32)
- #114510 (llvm-wrapper: adapt for LLVM API changes)
- #114562 (stabilize abi_thiscall)
- #114570 ([miri][typo] Fix a typo in a vector_block comment.)
- #114573 (CI: do not hide error logs in a group)
r? `@ghost`
`@rustbot` modify labels: rollup
CI: do not hide error logs in a group
This PR avoids creating a GHA group at the very end of a CI workflow when some failure has happened. Before, when a failure has happened, its GHA group was not closed, however the clock drift check function would create a new group, which would actually close the group containing the error log, thus making errors hidden by default, which is not ideal.
See discussion here: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/GHA.20groups.20being.20closed.20on.20failures
r? bootstrap
Bubble up nested goals from equation in `predicates_for_object_candidate`
This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)
r? `@lcnr`
Make `unconditional_recursion` warning detect recursive drops
Closes#55388
Also closes#50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965.
r? `@oli-obk` since you are the mentor for #55388
Unresolved questions:
- [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem.
`@rustbot` label +T-compiler +C-enhancement +A-lint
Don't provide `generate_default_from_new` when impl self ty is missing
Also don't provide the assist when the `Default` trait can't be found.
Part of #15398
internal: Turn unresolved proc macro expansions into missing expressions
Reduces the amount of type related errors one gets when proc macro expansion is disabled.
Optimize `Iterator` implementation for `&mut impl Iterator + Sized`
This adds a specialization trait to forward `fold`, `try_fold`,... to the inner iterator where possible
fix: Remove unwraps from "Generate delegate trait"
Fixes#15388
This is untested and purely mechanical, maybe some of those `unwrap`s actually made sense, but it probably doesn't hurt to avoid them.
Use the warning color when rust-analyzer is stopped
If the rust-analyzer server isn't running, we can't do much. Treat this state as a warning color, so it's more obvious.
SCIP: Qualify parameters by the containing function
SCIP requires symbols to be unique, but multiple functions may have a parameter with the same name. Qualify parameters according to the containing function.
SCIP requires symbols to be unique, but multiple functions may have a
parameter with the same name. Qualify parameters according to the
containing function.
Set the default status bar action to openLogs
Previously, clicking 'rust-analyzer' would stop the server entirely. This was easy to do accidentally, and then the user has to wait for the server to start up again.
Previously, clicking 'rust-analyzer' would stop the server
entirely. This was easy to do accidentally, and then the user has to
wait for the server to start up again.
Infer type in irrefutable slice patterns with fixed length as array
Fixes https://github.com/rust-lang/rust/issues/76342
In irrefutable slice patterns with a fixed length, we can infer the type as an array type. We now choose to prefer some implementations over others, e.g. in:
```
struct Zeroes;
const ARR: [usize; 2] = [0; 2];
const ARR2: [usize; 2] = [2; 2];
impl Into<&'static [usize; 2]> for Zeroes {
fn into(self) -> &'static [usize; 2] {
&ARR
}
}
impl Into<&'static [usize]> for Zeroes {
fn into(self) -> &'static [usize] {
&ARR2
}
}
fn main() {
let &[a, b] = Zeroes.into();
}
```
We now prefer the impl candidate `impl Into<&'static [usize; 2]> for Zeroes`, it's not entirely clear to me that this is correct, but given that the slice impl would require a type annotation anyway, this doesn't seem unreasonable.
r? `@lcnr`
Fix suggestion spans for expr from macro expansions
### Issue #112007: rustc shows expanded `writeln!` macro in code suggestion
#### Before This PR
```
help: consider using a semicolon here
|
6 | };
| +
help: you might have meant to return this value
--> C:\Users\hayle\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\macros\mod.rs:557:9
|
55| return $dst.write_fmt($crate::format_args_nl!($($arg)*));
| ++++++ +
```
#### After This PR
```
help: consider using a semicolon here
|
LL | };
| +
help: you might have meant to return this value
|
LL | return writeln!(w, "but not here");
| ++++++ +
```
### Issue #110017: `format!` `.into()` suggestion deletes the `format` macro
#### Before This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
--> /Users/eric/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/macros.rs:121:12
|
12| res.into()
| +++++++
```
#### After This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
|
LL | Err(format!("error: {x}").into())
| +++++++
```
---
Fixes#112007.
Fixes#110017.
Clarify documentation for `CStr`
* Better differentiate summaries for `from_bytes_until_nul` and `from_bytes_with_nul`
* Add some links where they may be helpful
Suggest `x build library` for a custom toolchain that fails to load `core`
Fixes#113222
The nicer suggestion for dev-channel won't be emitted if `-Z ui-testing` enabled. IMO, this is acceptable for now.
Exclude non-identifier aliases from completion filtering text
When building `CompletionItem`s, this excludes aliases that aren't valid identifiers from the "lookup" text used to filter completions in the LSP client. Including them results in weird completion filtering behavior e.g. `Partial>` matching a completion for the `PartialOrd` trait because it has a doc alias of ">".
Closes#14692
Add ExternCrateDecl to HIR
Adding these doesn't really require much design effort as they represent a single import, unlike use trees which are one item that represent 0 or more imports.
We only resolve to this definition when actually resolving on the name or alias of an `extern crate name as alias` item, not usages yet as that requires far more changes that won't lead anywhere without giving it more thought. Nevertheless the changes slightly improve IDE things, an example being hover on the decl showing the merged doc comments for example.
cc https://github.com/rust-lang/rust-analyzer/issues/14079
Filter out short-lived LLVM diagnostics before they reach the rustc handler
During profiling I saw remark passes being unconditionally enabled: for example `Machine Optimization Remark Emitter`.
The diagnostic remarks enabled by default are [from missed optimizations and opt analyses](https://github.com/rust-lang/rust/pull/113339#discussion_r1259480303). They are created by LLVM, passed to the diagnostic handler on the C++ side, emitted to rust, where they are unpacked, C++ strings are converted to rust, etc.
Then they are discarded in the vast majority of the time (i.e. unless some kind of `-Cremark` has enabled some of these passes' output to be printed).
These unneeded allocations are very short-lived, basically only lasting between the LLVM pass emitting them and the rust handler where they are discarded. So it doesn't hugely impact max-rss, and is only a slight reduction in instruction count (cachegrind reports a reduction between 0.3% and 0.5%) _on linux_. It's possible that targets without `jemalloc` or with a worse allocator, may optimize these less.
It is however significant in the aggregate, looking at the total number of allocated bytes:
- it's the biggest source of allocations according to dhat, on the benchmarks I've tried e.g. `syn` or `cargo`
- allocations on `syn` are reduced by 440MB, 17% (from 2440722647 bytes total, to 2030461328 bytes)
- allocations on `cargo` are reduced by 6.6GB, 19% (from 35371886402 bytes total, to 28723987743 bytes)
Some of these diagnostics objects [are allocated in LLVM](https://github.com/rust-lang/rust/pull/113339#discussion_r1252387484) *before* they're emitted to our diagnostic handler, where they'll be filtered out. So we could remove those in the future, but that will require changing a few LLVM call-sites upstream, so I left a FIXME.
