Commit Graph

25982 Commits

Author SHA1 Message Date
bors
08f0c29954 Auto merge of #14906 - davidbarsky:davidbarsky/add-option-to-disable-explorer, r=Veykril
fix: add a toggle to disable the dependency explorer

For common uses of non-Cargo build systems with rust-analyzer, the dependency view isn't particularly helpful because there isn't a Cargo.toml present for dependencies or the dependencies are part of the current workspace.

Speaking from the perspective of a user of `rust-project.json`, I'd prefer to have this feature disabled until I can add a field to `Crate` that defines the location of a build file (e.g., a `BUCK`) file, which would allow for removing the "search for a Cargo.toml in parent directories of a crate root" behavior that exists in a few places (I've opened [an issue](https://github.com/rust-lang/cargo/issues/12187) on Cargo to request this data from `cargo-metadata`).
2023-05-26 16:49:13 +00:00
David Barsky
7dfef85be6 fix: add a toggle to disable the dependency explorer. 2023-05-26 11:50:07 -04:00
bors
6bca9f2aac Auto merge of #14859 - lunacookies:qos, r=lunacookies
Specify thread types using Quality of Service API

<details>
<summary>Some background (in case you haven’t heard of QoS before)</summary>

Heterogenous multi-core CPUs are increasingly found in laptops and desktops (e.g. Alder Lake, Snapdragon 8cx Gen 3, M1). To maximize efficiency on this kind of hardware, it is important to provide the operating system with more information so threads can be scheduled on different core types appropriately.

The approach that XNU (the kernel of macOS, iOS, etc) and Windows have taken is to provide a high-level semantic API – quality of service, or QoS – which informs the OS of the program’s intent. For instance, you might specify that a thread is running a render loop for a game. This makes the OS provide this thread with as large a share of the system’s resources as possible. Specifying a thread is running an unimportant background task, on the other hand, is cause for it to be scheduled exclusively on high-efficiency cores instead of high-performance cores.

QoS APIs allows for easy configuration of many different parameters at once; for instance, setting QoS on XNU affects scheduling, timer latency, I/O priorities, and of course what core type the thread in question should run on. I don’t know any details on how QoS works on Windows, but I would guess it’s similar.

Hypothetically, taking advantage of these APIs would improve power consumption, thermals, battery life if applicable, etc.

</details>

# Relevance to rust-analyzer

From what I can tell the philosophy behind both the XNU and Windows QoS APIs is that _user interfaces should never stutter under any circumstances._ You can see this in the array of QoS classes which are available: the highest QoS class in both APIs is one intended explicitly for UI render loops.

Imagine rust-analyzer is performing CPU-intensive background work – maybe you just invoked Find Usages on `usize` or opened a large project – in this scenario the editor’s render loop should absolutely get higher priority than rust-analyzer, no matter what. You could view it in terms of “realtime-ness”: flight control software is hard realtime, audio software is soft realtime, GUIs are softer realtime, and rust-analyzer is not realtime at all. Of course, maximizing responsiveness is important, but respecting the rest of the system is more important.

# Implementation

I’ve tried my best to unify thread creation in `stdx`, where the new API I’ve introduced _requires_ specifying a QoS class. Different points along the performance/efficiency curve can make a great difference; the M1’s e-cores use around three times less power than the p-cores, so putting in this effort is worthwhile IMO.

It’s worth mentioning that Linux does not [yet](https://youtu.be/RfgPWpTwTQo) have a QoS API. Maybe translating QoS into regular thread priorities would be acceptable? From what I can tell the only scheduling-related code in rust-analyzer is Windows-specific, so ignoring QoS entirely on Linux shouldn’t cause any new issues. Also, I haven’t implemented support for the Windows QoS APIs because I don’t have a Windows machine to test on, and because I’m completely unfamiliar with Windows APIs :)

I noticed that rust-analyzer handles some requests on the main thread (using `.on_sync()`) and others on a threadpool (using `.on()`). I think it would make sense to run the main thread at the User Initiated QoS and the threadpool at Utility, but only if all requests that are caused by typing use `.on_sync()` and all that don’t use `.on()`. I don’t understand how the `.on_sync()`/`.on()` split that’s currently present was chosen, so I’ve let this code be for the moment. Let me know if changing this to what I proposed makes any sense.

To avoid having to change everything back in case I’ve misunderstood something, I’ve left all threads at the Utility QoS for now. Of course, this isn’t what I hope the code will look like in the end, but I figured I have to start somewhere :P

# References

<ul>

<li><a href="https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/PrioritizeWorkAtTheTaskLevel.html">Apple documentation related to QoS</a></li>
<li><a href="67e155c940/include/pthread/qos.h">pthread API for setting QoS on XNU</a></li>
<li><a href="https://learn.microsoft.com/en-us/windows/win32/procthread/quality-of-service">Windows’s QoS classes</a></li>
<li>
<details>
<summary>Full documentation of XNU QoS classes. This documentation is only available as a huge not-very-readable comment in a header file, so I’ve reformatted it and put it here for reference.</summary>
<ul>
<li><p><strong><code>QOS_CLASS_USER_INTERACTIVE</code>: A QOS class which indicates work performed by this thread is interactive with the user.</strong></p><p>Such work is requested to run at high priority relative to other work on the system. Specifying this QOS class is a request to run with nearly all available system CPU and I/O bandwidth even under contention. This is not an energy-efficient QOS class to use for large tasks. The use of this QOS class should be limited to critical interaction with the user such as handling events on the main event loop, view drawing, animation, etc.</p></li>
<li><p><strong><code>QOS_CLASS_USER_INITIATED</code>: A QOS class which indicates work performed by this thread was initiated by the user and that the user is likely waiting for the results.</strong></p><p>Such work is requested to run at a priority below critical user-interactive work, but relatively higher than other work on the system. This is not an energy-efficient QOS class to use for large tasks. Its use should be limited to operations of short enough duration that the user is unlikely to switch tasks while waiting for the results. Typical user-initiated work will have progress indicated by the display of placeholder content or modal user interface.</p></li>
<li><p><strong><code>QOS_CLASS_DEFAULT</code>: A default QOS class used by the system in cases where more specific QOS class information is not available.</strong></p><p>Such work is requested to run at a priority below critical user-interactive and user-initiated work, but relatively higher than utility and background tasks. Threads created by <code>pthread_create()</code> without an attribute specifying a QOS class will default to <code>QOS_CLASS_DEFAULT</code>. This QOS class value is not intended to be used as a work classification, it should only be set when propagating or restoring QOS class values provided by the system.</p></li>
<li><p><strong><code>QOS_CLASS_UTILITY</code>: A QOS class which indicates work performed by this thread may or may not be initiated by the user and that the user is unlikely to be immediately waiting for the results.</strong></p><p>Such work is requested to run at a priority below critical user-interactive and user-initiated work, but relatively higher than low-level system maintenance tasks. The use of this QOS class indicates the work should be run in an energy and thermally-efficient manner. The progress of utility work may or may not be indicated to the user, but the effect of such work is user-visible.</p></li>
<li><p><strong><code>QOS_CLASS_BACKGROUND</code>: A QOS class which indicates work performed by this thread was not initiated by the user and that the user may be unaware of the results.</strong></p><p>Such work is requested to run at a priority below other work. The use of this QOS class indicates the work should be run in the most energy and thermally-efficient manner.</p></li>
<li><p><strong><code>QOS_CLASS_UNSPECIFIED</code>: A QOS class value which indicates the absence or removal of QOS class information.</strong></p><p>As an API return value, may indicate that threads or pthread attributes were configured with legacy API incompatible or in conflict with the QOS class system.</p></li>
</ul>
</details>
</li>

</ul>
2023-05-26 15:48:22 +00:00
bors
3713c4b949 Auto merge of #14904 - Veykril:hover-hex, r=Veykril
Render size, align and offset hover values in hex

Arguably, these values are usually almost always viewed in hex format so I think we should do the same here
2023-05-26 14:59:41 +00:00
Lukas Wirth
be9cc0baae Render size, align and offset hover values in hex 2023-05-26 16:41:45 +02:00
bors
eee6872647 Auto merge of #14901 - Veykril:errors, r=Veykril
internal: Move flycheck and config errors to status notification

cc https://github.com/rust-lang/rust-analyzer/issues/14193
2023-05-26 13:38:39 +00:00
Lukas Wirth
f876adf617 Report flycheck errors via status 2023-05-26 15:37:41 +02:00
Lukas Wirth
a2b59b110f Report config errors via status 2023-05-26 15:26:03 +02:00
Lukas Wirth
79fe11ced3 Shuffle some things around 2023-05-26 15:09:19 +02:00
bors
e963846656 Auto merge of #14816 - justahero:gh-14626, r=Veykril
feat: Assist to replace generic with impl trait

This adds a new assist named "Replace named generic with impl". It is the inverse operation to the existing "Replace impl trait with generic" assist.

It allows to refactor the following statement:

```rust
//      👇 cursor
fn new<T$0: ToString>(input: T) -> Self {}
```

to be transformed into:

```rust
fn new(input: impl ToString) -> Self {}
```

* adds new helper function `impl_trait_type` to create AST node
* add method to remove an existing generic param type from param list

Closes #14626
2023-05-26 12:03:44 +00:00
Sebastian Ziebell
e78df83e2f Integrate feedback
* pass in existing `Semantics` object to function
* pass in `Definition` for param type
* refactor iterator to use `flatten`
2023-05-26 13:43:12 +02:00
bors
8589a2d843 Auto merge of #14849 - alibektas:14557n, r=Veykril
enhancement : using doc aliases to search workspace symbols  ( fixes #14557 )

Doc aliases are now visible among symbols and can be used for searching.
2023-05-26 11:30:40 +00:00
Ali Bektas
d49924dc6e Choose & over ref, make nav target's name more intuitive. 2023-05-26 13:24:44 +02:00
Sebastian Ziebell
ce1c85317f Check param is not referenced in function
This checks the type param is referenced neither in the function body
nor as a return type.

* add tests
2023-05-26 13:24:29 +02:00
Sebastian Ziebell
95f59668e6 Fix removal of generic param from list
This removes an existing generic param from the `GenericParamList`. It
also considers to remove the extra colon & whitespace to the previous
sibling.

* change order to get all param types first and mark them as mutable
  before the first edit happens
* add helper function to remove a generic parameter
* fix test output
2023-05-26 13:13:15 +02:00
Sebastian Ziebell
59f8827a6f Implement assist to replace named generic with impl
This adds a new assist named "replace named generic with impl" to move
the generic param type from the generic param list into the function
signature.

```rust
fn new<T: ToString>(input: T) -> Self {}
```

becomes

```rust
fn new(input: impl ToString) -> Self {}
```

The first step is to determine if the assist can be applied, there has
to be a match between generic trait param & function paramter types.

* replace function parameter type(s) with impl
* add new `impl_trait_type` function to generate the new trait bounds with `impl` keyword  for use in the
  function signature
2023-05-26 13:13:11 +02:00
bors
2fd9260472 Auto merge of #14897 - HKalbasi:dev, r=HKalbasi
Insert type vars in function arguments

follow up #14891
2023-05-26 10:56:39 +00:00
hkalbasi
c21d09f3cc insert type vars in function arguments 2023-05-26 14:26:13 +03:30
bors
b4e3fec176 Auto merge of #14895 - lowr:fix/goto-type-def-tokens-in-tt, r=Veykril
fix: don't try determining type of token inside macro calls

When we're requested `Go to Type Definition`, we first downmap the token in question to tokens in every macro call expansion involved, and then determine the type of those mapped tokens by looking for the nearest ancestor node that is either expression or pattern (or a few others). This procedure has one flaw: When the downmapped token is inside another macro call, the nearest ancestor node to retrieve the type of is *that* macro call. That's not what we should return in general and therefore we should disregard it.

Notably, now that we expand built-in `format_arg!` and its family macros, we're always returning [`Arguments`] when one `Go to Type Definition` at `dbg!(variable$0)` along with the actual type of `variable` without this patch.

[`Arguments`]: https://doc.rust-lang.org/nightly/core/fmt/struct.Arguments.html
2023-05-26 10:01:11 +00:00
Ryo Yoshida
397c8e5148
fix: don't try determining type of token inside macro calls 2023-05-26 16:46:45 +09:00
bors
615aaa4751 Auto merge of #14894 - Wilfred:index_scip_path, r=lnicola
Allow users to override the .scip output file path

Previously, rust-analyzer would write to the file index.scip unconditionally.
2023-05-26 06:25:34 +00:00
Wilfred Hughes
5b0e170683 Allow users to override the .scip output file path
Previously, rust-analyzer would write to the file index.scip
unconditionally.
2023-05-25 16:54:31 -07:00
bors
06d02e0a1e Auto merge of #14893 - HKalbasi:dev, r=HKalbasi
Fix `need-mut` false positive in closure capture of match scrutinee

Fix `need-mut` false positive on self.
2023-05-25 22:48:08 +00:00
hkalbasi
780349bdaf fix need-mut false positive in closure capture of match scrutinee 2023-05-26 02:08:37 +03:30
bors
fcd3a6b037 Auto merge of #14891 - HKalbasi:dev, r=HKalbasi
Evaluate `UnevaluatedConst` in unify

fix #14844
2023-05-25 16:09:39 +00:00
hkalbasi
7ef185d65e evaluate UnevaluatedConst in unify 2023-05-25 19:37:20 +03:30
bors
efd3094aba Auto merge of #14890 - HKalbasi:dev, r=HKalbasi
use `::core` instead of `$crate` in `option_env!`

fix #14885
2023-05-25 15:19:18 +00:00
hkalbasi
b0f17668f7 use ::core instead of $crate in option_env! 2023-05-25 18:46:34 +03:30
bors
1c6561320f Auto merge of #14889 - Veykril:overly-dbg, r=Veykril
Add context to overly long loop message
2023-05-25 15:01:08 +00:00
Lukas Wirth
e3dfcf2eb2 Add context to overly long loop message 2023-05-25 16:20:28 +02:00
bors
21e5dc2af9 Auto merge of #14881 - Veykril:name-display, r=Veykril
internal: Replace Display impl for Name

This allows us to plug in interner for `Name`s that live inside the database.
2023-05-25 12:04:16 +00:00
alibektas
1222869b3e Fix #14557. Docs aliases can now be detected and used in searching for workspace symbols 2023-05-24 23:57:24 +02:00
bors
a512774fd9 Auto merge of #14752 - ponyii:fix/generate_derive_breaks_indentation, r=Veykril
fix: assists no longer break indentation

Fixes https://github.com/rust-lang/rust-analyzer/issues/14674

These are _ad hoc_ patches for a number of assists that can produce incorrectly indented code, namely:
- generate_derive
- add_missing_impl_members
- add_missing_default_members

Some general solution is required in future, as the same problem arises in many other assists, e.g.
- replace_derive_with...
- generate_default_from_enum...
- generate_default_from_new
- generate_delegate_methods
(the list is incomplete)
2023-05-24 18:58:07 +00:00
Lukas Wirth
c7ef6c25b7 internal: Replace Display impl for Name 2023-05-24 20:55:12 +02:00
bors
2f840c2236 Auto merge of #14874 - Veykril:crate-cfg, r=Veykril
expand: Change how `#![cfg(FALSE)]` behaves on crate root

Closes https://github.com/rust-lang/rust-analyzer/issues/14769
2023-05-24 16:06:09 +00:00
Luna Razzaghipour
430bdd3509
Run the main thread under the User Interactive QoS class 2023-05-25 00:22:14 +10:00
Luna Razzaghipour
578d99477a
Move on-type formatting request handler onto the main thread 2023-05-25 00:16:52 +10:00
bors
8ad70e7f99 Auto merge of #14866 - AndreasBackx:feature/doc-comments-markdown, r=Veykril
[editors/code] add markdown syntax highlighting to doc comments

_This is a continuation of https://github.com/microsoft/vscode/pull/169956 and https://github.com/dustypomerleau/rust-syntax/pull/37 (that repo is no longer maintained: https://github.com/dustypomerleau/rust-syntax/issues/39#issuecomment-1427339029). The VS Code team seemed to prefer this being inside of an extension._

This adds Markdown highlighting to doc comment lines and blocks. Currently it is thus regarded both as a comment and as Markdown which leads to normally foreground text being in the colour of the comment and the rest highlighted like Markdown or its own embedded languages in code blocks.

![image](https://github.com/rust-lang/rust-analyzer/assets/1593486/c84f2e83-faea-47ca-853d-3728a07b2b66)

![image](https://github.com/rust-lang/rust-analyzer/assets/1593486/f4191425-32cd-451c-ae3a-29a0970ce7a2)

Block comments are supported, but currently not when there is a `*` at the start of the line:
![image](https://github.com/rust-lang/rust-analyzer/assets/1593486/ce3b58d5-9dca-4376-bffe-4f5a54acbe37)
![image](https://github.com/rust-lang/rust-analyzer/assets/1593486/b73a5ee6-a178-4aef-a0e4-3d75e4e7d8e5)

I'm not entirely sure if I can easily fix this, I'd need to find a way to make the content ignore the `*`. Though I'm unsure if it's important as there are [conventions against using block comments](
https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#use-line-comments) and using them without `*` does work. All of this TextMate grammar is so hard to find documentation on that _honestly_ I'd just not want to support this considering the effort.

Let me know what everyone thinks of this being in rust-analyzer. I've personally found it hard to write large amounts of Rust documentation due to the lack of Markdown syntax highlighting.

Also, thank you `@adenine-dev` as well for making this available in the interim and your enthousiasm. Wanted to get this PR out sooner, but life gets in the way.
2023-05-24 11:33:41 +00:00
bors
2df56cadcb Auto merge of #14755 - poliorcetics:clippy-fixes, r=Veykril
Fix: a TODO and some clippy fixes

- fix(todo): implement IntoIterator for ArenaMap<IDX, V>
- chore: remove unused method
- fix: remove useless `return`s
- fix: various clippy lints
- fix: simplify boolean test to a single negation
2023-05-24 11:13:52 +00:00
Lukas Wirth
74d6826858 expand: Change how #![cfg(FALSE)] behaves on crate root 2023-05-24 13:02:38 +02:00
bors
1d1a1195f3 Auto merge of #14880 - Veykril:intern-double, r=Veykril
Remove double lookups from Interned
2023-05-24 10:58:46 +00:00
Lukas Wirth
12d4355c60 Remove double lookups from Interned 2023-05-24 12:54:25 +02:00
alibektas
51ec2ced69 Improve ast::make
Add `ty_alias` and make `impl_trait` , `fn` and `impl_` have more coverage.
2023-05-23 03:12:57 +02:00
bors
2120c913c2 Auto merge of #14872 - lowr:fix/ref-pat-with-type-var, r=HKalbasi
fix: introduce new type var when expectation for ref pat is not ref

Fixes #14840

When we infer the type of ref patterns, its expected type may not be reference type: 1) expected type is an unresolved inference variable, or 2) expected type is erroneously other kind of type. In either case, we should produce a reference type with a new type variable rather than an error type so that we can continue inferring the inner patterns without further errors because of the (possible) type mismatch of this pattern.
2023-05-22 19:53:39 +00:00
Ryo Yoshida
01f42d2405
fix: introduce new type var when expectation for ref pat is not ref 2023-05-22 23:13:41 +09:00
Andreas Backx
09f624721c
[editors/code] add markdown syntax highlighting to doc comments 2023-05-21 17:34:42 +01:00
bors
7ac161ce77 Auto merge of #14863 - lowr:fix/extract-fn-nested-tt, r=lnicola
fix: consider all tokens in macro expr when analyzing locals

Fixes #14687

2 fixes for `extract_function` assist (related closely enough that I squashed into one commit):

- Locals in macro expressions have been analyzed only when they are in the top-level token tree the macro call wraps. We should consider all descendant tokens.
- `self` in macro expressions haven't been analyzed.
2023-05-21 12:40:29 +00:00
Ryo Yoshida
7b70988d48
fix: consider all tokens in macro expr when analyzing locals
Also consider `self` token along with ordinary identifiers.
2023-05-21 20:07:36 +09:00
bors
a04d8456be Auto merge of #14855 - HKalbasi:mir, r=HKalbasi
Consider block impls in `lookup_impl_assoc_item_for_trait_ref`

fix #14782
2023-05-20 20:55:22 +00:00
Luna Razzaghipour
a416248296
Extract platform-specific QoS code into module 2023-05-21 02:48:30 +10:00