New assist: move_format_string_arg
The name might need some improving.
```rust
fn main() {
print!("{x + 1}");
}
```
to
```rust
fn main() {
print!("{}"$0, x + 1);
}
```
fixes#13180
ref to #5988 for similar work
* extracted `format_like`'s parser to it's own module in `ide-db`
* reworked the parser's API to be more direct
* added assist to extract expressions in format args
fix: handle lifetime variables in projection normalization
Fixes#12674
The problem is that we've been skipping the binders of normalized projections assuming they should be empty, but the assumption is unfortunately wrong. We may get back lifetime variables and should handle them before returning them as normalized projections. For those who are curious why we get those even though we treat all lifetimes as 'static, [this comment in chalk](d875af0ff1/chalk-solve/src/infer/unify.rs (L888-L908)) may be interesting.
I thought using `InferenceTable` would be cleaner than the other ways as it already has the methods for canonicalization, normalizing projection, and resolving variables, so moved goal building and trait solving logic to a new `HirDatabase` query. I made it transparent query as the query itself doesn't do much work but the eventual call to `HirDatabase::trait_solve_query()` does.
Remove the toggleInlayHints command from VSCode
Inlay hints are no longer something specifc to r-a as it has been upstreamed into the LSP, we don't have a reason to give the config for this feature special treatment in regards to toggling. There are plenty of other options out there in the VSCode marketplace to create toggle commands/hotkeys for configurations in general which I believe we should nudge people towards instead.
fix: handle trait methods as inherent methods for trait-related types
Fixes#10677
When resolving methods for trait object types and placeholder types that are bounded by traits, we need to count the methods of the trait and its super traits as inherent methods. This matters because these trait methods have higher priority than the other traits' methods.
Relevant code in rustc: [`assemble_inherent_candidates_from_object()`](0631ea5d73/compiler/rustc_typeck/src/check/method/probe.rs (L783-L792)) for trait object types, [`assemble_inherent_candidates_from_param()`](0631ea5d73/compiler/rustc_typeck/src/check/method/probe.rs (L838-L847)) for placeholder types. Notice the second arg of `push_candidate()` is `is_inherent`.
Remove redundant 'resolve_obligations_as_possible' call
Hi! I was looking for a "good first issue" and saw this one: https://github.com/rust-lang/rust-analyzer/issues/7542. I like searching for performance improvements, so I wanted to try to find something useful there.
There are two tests in integrated_benchmarks.rs, I looked at 'integrated_highlighting_benchmark' (not the one discussed in the issue above).
Profile from that test looks like this:
```
$ RUN_SLOW_BENCHES=1 cargo test --release --package rust-analyzer --lib -- integrated_benchmarks::integrated_highlighting_benchmark --exact --nocapture
Finished release [optimized] target(s) in 0.06s
Running unittests src/lib.rs (target/release/deps/rust_analyzer-a80ca6bb8f877458)
running 1 test
workspace loading: 358.45ms
initial: 9.60s
change: 13.96µs
cpu profiling is disabled, uncomment `default = [ "cpu_profiler" ]` in Cargo.toml to enable.
273ms - highlight
143ms - infer:wait @ per_query_memory_usage
143ms - infer_query
0 - crate_def_map:wait (3165 calls)
4ms - deref_by_trait (967 calls)
96ms - resolve_obligations_as_possible (22106 calls)
0 - trait_solve::wait (2068 calls)
21ms - Semantics::analyze_impl (18 calls)
0 - SourceBinder::to_module_def (20 calls)
36ms - classify_name (19 calls)
19ms - classify_name_ref (308 calls)
0 - crate_def_map:wait (461 calls)
4ms - descend_into_macros (628 calls)
0 - generic_params_query (4 calls)
0 - impl_data_with_diagnostics_query (1 calls)
45ms - infer:wait (37 calls)
0 - resolve_obligations_as_possible (2 calls)
0 - source_file_to_def (1 calls)
0 - trait_solve::wait (42 calls)
after change: 275.23ms
test integrated_benchmarks::integrated_highlighting_benchmark ... ok
```
22106 calls to `resolve_obligations_as_possible` seem like the main issue there.
One thing I noticed (and fixed in this PR) is that `InferenceContext::resolve_ty_shallow` first calls `resolve_obligations_as_possible`, and then calls `InferenceTable::resolve_ty_shallow`. But `InferenceTable::resolve_ty_shallow` [inside](2e9f1204ca/crates/hir-ty/src/infer/unify.rs (L372)) again calls `resolve_obligations_as_possible`.
`resolve_obligations_as_possible` inside has a while loop, which works until it can't find any helpful information. So calling this function for the second time does nothing, so one of the calls could be safely removed.
`InferenceContext::resolve_ty_shallow` is actually quite a hot place, and after fixing it, the total number of `resolve_obligations_as_possible` in this test is reduced to 15516 (from 22106). "After change" time also improves from ~270ms to ~240ms, which is not a very huge win, but still something measurable.
Same profile after PR:
```
$ RUN_SLOW_BENCHES=1 cargo test --release --package rust-analyzer --lib -- integrated_benchmarks::integrated_highlighting_benchmark --exact --nocapture
Finished release [optimized] target(s) in 0.06s
Running unittests src/lib.rs (target/release/deps/rust_analyzer-a80ca6bb8f877458)
running 1 test
workspace loading: 339.86ms
initial: 9.28s
change: 10.69µs
cpu profiling is disabled, uncomment `default = [ "cpu_profiler" ]` in Cargo.toml to enable.
236ms - highlight
110ms - infer:wait @ per_query_memory_usage
110ms - infer_query
0 - crate_def_map:wait (3165 calls)
4ms - deref_by_trait (967 calls)
64ms - resolve_obligations_as_possible (15516 calls)
0 - trait_solve::wait (2068 calls)
21ms - Semantics::analyze_impl (18 calls)
0 - SourceBinder::to_module_def (20 calls)
34ms - classify_name (19 calls)
18ms - classify_name_ref (308 calls)
0 - crate_def_map:wait (461 calls)
3ms - descend_into_macros (628 calls)
0 - generic_params_query (4 calls)
0 - impl_data_with_diagnostics_query (1 calls)
45ms - infer:wait (37 calls)
0 - resolve_obligations_as_possible (2 calls)
0 - source_file_to_def (1 calls)
0 - trait_solve::wait (42 calls)
after change: 238.15ms
test integrated_benchmarks::integrated_highlighting_benchmark ... ok
```
The performance of this test could be further improved but at the cost of making code more complicated, so I wanted to check if such a change is desirable before sending another PR.
`resolve_obligations_as_possible` is actually called a lot of times even when no new information was provided. As I understand, `resolve_obligations_as_possible` could do something useful only if some variables/values were unified since the last check. We can store a boolean variable inside `InferenceTable`, which indicates if `try_unify` was called after last `resolve_obligations_as_possible`. If it wasn't called, we can safely not call `resolve_obligations_as_possible` again.
I tested this change locally, and it reduces the number of `resolve_obligations_as_possible` to several thousand (it is not shown in the profile anymore, so don't know the exact number), and the total time is reduced to ~180ms. Here is a generated profile:
```
$ RUN_SLOW_BENCHES=1 cargo test --release --package rust-analyzer --lib -- integrated_benchmarks::integrated_highlighting_benchmark --exact --nocapture
Finished release [optimized] target(s) in 0.06s
Running unittests src/lib.rs (target/release/deps/rust_analyzer-a80ca6bb8f877458)
running 1 test
workspace loading: 349.92ms
initial: 8.56s
change: 11.32µs
cpu profiling is disabled, uncomment `default = [ "cpu_profiler" ]` in Cargo.toml to enable.
175ms - highlight
21ms - Semantics::analyze_impl (18 calls)
0 - SourceBinder::to_module_def (20 calls)
33ms - classify_name (19 calls)
17ms - classify_name_ref (308 calls)
0 - crate_def_map:wait (461 calls)
3ms - descend_into_macros (628 calls)
0 - generic_params_query (4 calls)
0 - impl_data_with_diagnostics_query (1 calls)
97ms - infer:wait (38 calls)
0 - resolve_obligations_as_possible (2 calls)
0 - source_file_to_def (1 calls)
0 - trait_solve::wait (42 calls)
after change: 177.04ms
test integrated_benchmarks::integrated_highlighting_benchmark ... ok
```
Let me know if adding a new bool field seems like a reasonable tradeoff, so I can send a PR.
Previously, annotations would only appear above the name of an item (function signature, struct declaration, etc).
Now, rust-analyzer can be configured to show annotations either above the name or above the whole item (including doc comments and attributes).
Check if TCS is a null pointer on SGX
The `EENTER` instruction only checks if the TCS is aligned, not if it zero. Saying the address returned is a `NonNull<u8>` (for which `Tcs` is a type alias) is unsound. As well-behaved runners will not put the TCS at address zero, so the definition of `Tcs` is correct. However, `std` should check the address before casting it to a `NonNull`.
ping `@jethrogb` `@raoulstrackx`
`@rustbot` label I-unsound
Build release artifact against older Glibc
When GitHub [deprecated Ubuntu 18.04](https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/) runners, rust-analyzer was forced to bump runners to 20.04 which includes an updated Glib. This renders RA incompatible with the still popular Ubuntu 18.04 and other slightly older distro versions.
Until a deprecation plan is announced on RA's side, I propose binaries shall be built against older glibc to maintain compatibility.
This PR changes the Release CI workflow to build the `linux-x64/x86_64-unknown-linux-gnu` release in an Ubuntu 18.04 container.
Fixes#13081 and #13085
Optimize thread parking on NetBSD
As the futex syscall is not present in the latest stable release, NetBSD cannot use the efficient thread parker and locks Linux uses. Currently, it therefore relies on a pthread-based parker, consisting of a mutex and semaphore which protect a state variable. NetBSD however has more efficient syscalls available: [`_lwp_park`](https://man.netbsd.org/_lwp_park.2) and [`_lwp_unpark`](https://man.netbsd.org/_lwp_unpark.2). These already provide the exact semantics of `thread::park` and `Thread::unpark`, but work with thread ids. In `std`, this ID is here stored in an atomic state variable, which is also used to optimize cases were the parking token is already available at the time `thread::park` is called.
r? `@m-ou-se`
The name might need some improving.
extract format_like's parser to it's own module in ide-db
reworked the parser's API to be more direct
added assist to extract expressions in format args
Inlay hints are no longer something specifc to r-a as it has been
upstreamed into the LSP, we don't have a reason to give the config
for this feature special treatment in regards to toggling. There are
plenty of other options out there in the VSCode marketplace to create
toggle commands/hotkeys for configurations in general which I believe
we should nudge people towards instead.
The `<*const T>::guaranteed_*` methods now return an option for the unknown case
cc https://github.com/rust-lang/rust/issues/53020#issuecomment-1236932443
I chose `0` for "not equal" and `1` for "equal" and left `2` for the unknown case so backends can just forward to raw pointer equality and it works ✨
r? `@fee1-dead` or `@lcnr`
cc `@rust-lang/wg-const-eval`
Stabilize raw-dylib for non-x86
This stabilizes the `raw-dylib` and `link_ordinal` features (#58713) for non-x86 architectures (i.e., `x86_64`, `aarch64` and `thumbv7a`):
* Marked the `raw_dylib` feature as `active`.
* Marked the `link_ordinal` attribute as `ungated`.
* Added new errors if either feature is used on x86 targets without the `raw_dylib` feature being enabled.
* Updated tests to only set the `raw_dylib` feature when building for x86.
Normalize before erasing late-bound regions in `equal_up_to_regions`
Normalize erasing regions **first**, before passing the type through a `BottomUpFolder` which erases late-bound regions too.
The root cause of this issue is due to 96d4137deed6c52c6db2dd19568c37d1c160f1e7, which removes a `normalize_erasing_regions` that happens before this call to `equal_up_to_regions`. While reverting that commit might be a fix, I think it was suspicious to be erasing late-bound regions first _then_ normalizing types in the first place in `equal_up_to_regions`.
-----
I am tempted to ask the reviewer to review and `r+` this without a UI test, since the existing issues that I think this fixes are all incredibly difficult to minimize (anything hyper/warp related, given the nature of those libraries 😓) or impossible to reproduce locally (the miri test), namely:
* This recently reported issue with tokio + warp: #101430
* This issue from `@RalfJung` about Miri being broken: #101344
* This additional issue reported in a comment by `@tmandry` (issue with fuchsia + hyper): https://github.com/rust-lang/rust/issues/101344#issuecomment-1235974564
I have locally verified that the repro in #101430 is fixed with this PR, but after a couple of hours of attempting to minimize this error and either failing to actually repro the ICE, or being overwhelmed with the number of traits and functions I need to inline into a UI test, I have basically given up. Thoughts are appreciated on how best to handle this.
r? `@oli-obk` who is at the intersection of MIR and types-related stuff who may be able to give advice 😅
Fix `-Zgcc-ld=lld`
`-Zgcc-ld=lld` is currently broken. CI is currently ignoring its tests.
cc `@Mark-Simulacrum` on the `compiletest` change: I'm not sure which of `bootstrap`'s test step or `compiletest` is currently incorrect wrt windows' `--compile-lib-path`. Since `sysroot/bin` is passed on windows, that means that `compiletest` can't find `rust-lld` on windows and tests are currently ignored: it's looking for something that is in `sysroot/lib` instead.
They are currently ignored on unixes for a different reason: the lld wrapper has a different name than what is checked.
(I've changed `compiletest` in this PR, just because I could make a very targeted change there, whereas completely changing the intentional lib path that is passed seemed it'd have wider reaching implications on all tests.)
And in both unix/win cases, I've changed the detection to look for `rust-lld` rather than the wrappers in `bin/gcc-ld/`. It seems like the more stable of all these executable names.
r? `@petrochenkov`
I've tested the `lld-wrapper` change on linux and osx, but couldn't test on windows gnu targets (I only have MSVC targets, and these can't use `rust-lld` via `-Zgcc-ld=lld`, nor do they use the lld wrapper IIUC).
I'd expect it to work whether or not the wrapper is called with or without an executable suffix. But at least now CI should test it in these targets.
Fixes#101370.
Open a BCrypt algorithm handle
Fixes#101474, supplants #101456.
Replaces use of a pseduo handle with manually opening a algorithm handle.
Most interesting thing here is the atomics.
r? `@thomcc`
