Commit Graph

27677 Commits

Author SHA1 Message Date
Laurențiu Nicola
c738655188 Set channel override when querying the sysroot metadata 2024-02-14 08:45:11 +02:00
bors
113f054274 Auto merge of #16558 - Wilfred:json_project_ts, r=lnicola
Update JsonProject to include optional fields

These were documented in #15014 in the manual, but this definition wasn't updated to match.
2024-02-14 06:24:56 +00:00
Wilfred Hughes
931f563a89 Update JsonProject to include optional fields
These were documented in #15014 in the manual, but this definition
wasn't updated to match.
2024-02-13 14:29:20 -08:00
bors
a02a219773 Auto merge of #16554 - Veykril:proc-macro-cargo-config-env, r=Veykril
fix: Pass .cargo/config.toml env vars to proc-macro server

Fixes https://github.com/rust-lang/rust-analyzer/issues/13976
2024-02-13 18:43:37 +00:00
Lukas Wirth
a981db53fa fix: Pass .cargo/config.toml env vars to proc-macro server 2024-02-13 19:42:03 +01:00
bors
2c05da15a9 Auto merge of #16553 - Veykril:field-lit-recovery, r=Veykril
fix: Imrpove recover on `=` for record field initializer and pattern
2024-02-13 17:28:36 +00:00
Lukas Wirth
bf115a6064 fix: Recover from = in record pattern field 2024-02-13 18:25:40 +01:00
Lukas Wirth
ccccc299c8 fix: Recover from = in record constructor field assignment 2024-02-13 18:23:33 +01:00
bors
fc1ee6136c Auto merge of #16544 - dfireBird:impl_trait_completion, r=Veykril
Add completions to show only traits in trait `impl` statement

This is prerequisite PR for adding the assist mentioned in #12500

P.S: If wanted, I will add the implementation of the assist in this PR as well.
2024-02-13 16:38:35 +00:00
Lukas Wirth
7f661782cd
Simplify 2024-02-13 17:26:14 +01:00
bors
22ca3fd89d Auto merge of #16550 - DavisVaughan:feature/activate-on-top-level-cargo-toml, r=Veykril
Activate on top level `Cargo.toml` and `rust-project.json` files

I believe there is an issue with how rust-analyzer is activated from within a VS Code project.

IIUC, the intent is that when you open a rust project with a top level `Cargo.toml`, then rust-analyzer should just start right up due to a VS Code activation event. This is not currently the case. i.e. run something like `cargo new ~/Desktop/hithere`, then open that folder in VS Code:

https://github.com/rust-lang/rust-analyzer/assets/19150088/1608b985-fd88-4174-a22a-5b3dd0fad84b

It is not until you actually open a Rust file that the extension starts up.

It looks like this was introduced in https://github.com/rust-lang/rust-analyzer/pull/10442. I do agree that recursive searching with `**/` is likely overkill, but I'm not sure `*/Cargo.toml` is working as expected in this comment (https://github.com/rust-lang/rust-analyzer/pull/10442#issuecomment-932967421):

> For some reason, */Cargo.toml works for both Cargo.toml in the project root and in a subdirectory (but not two levels deep).

That does not seem to be the case for me. I even went into VS Code itself and added some fake tests for `glob.match()` (which is eventually what gets used for this) and `*/Cargo.toml` doesn't seem to match a top level `Cargo.toml` (and I think that makes sense).

<img width="1087" alt="Screenshot 2024-02-12 at 6 07 08 PM" src="https://github.com/rust-lang/rust-analyzer/assets/19150088/510b0aaa-ac66-48b1-a9e2-a3bdfc237c48">

Lastly, the VS Code search filtering uses the same glob patterns, and it also doesn't match with `*/Cargo.toml`:

https://github.com/rust-lang/rust-analyzer/assets/19150088/4973f5e7-270d-489a-8db4-37469ffe12df

---

If you want both top level `Cargo.toml`s and 1-level-deep `Cargo.toml`s to be detected by VS Code's activation events, then I think we need to lay both of those conditions out explicitly, which I've done in this PR. That does fix the problem for me.

https://github.com/rust-lang/rust-analyzer/assets/19150088/bfcb1223-c45c-479a-9ea4-4be3f36e6838
2024-02-13 16:26:01 +00:00
dfireBird
0e47befaf3
fix flyimport showing other types in impl trait statement 2024-02-13 19:31:04 +05:30
dfireBird
9897662bf7
add completions to show only traits with qualified path prefix 2024-02-13 18:41:24 +05:30
bors
3c4d642d8b Auto merge of #16117 - mustakimali:mo-order, r=Veykril
feat: completion list suggests constructor like & builder methods first

When typing `MyType::` the completion items' order could be re-ordered based on how likely we want to select those:
* Constructors: `new` like functions to be able to create the type,
* Constructors that take args: Any other function that creates `Self`,
* Builder Methods: any builder methods available,
* Regular methods & associated functions (no change there)

![image](https://github.com/rust-lang/rust-analyzer/assets/1546896/54593b91-07b3-455a-8a71-8d203d4eaf4a)

In this photo, the order is:
* `new` constructor is first
* `new_builder` second is a builder method
* `aaaanew` is a constructor that takes arguments, is third  and is irrespective of its alphabetical order among names.

---

Another Example using actix `HttpServer` shows preferring constructor without `self` arg first (the `new` method)

![image](https://github.com/rust-lang/rust-analyzer/assets/1546896/938d3fb0-3d7a-4427-ae2f-ec02a834ccbe)

![image](https://github.com/rust-lang/rust-analyzer/assets/1546896/2c13860c-efd1-459d-b25e-df8adb61bbd0)

I've dropped my previous idea of highlighting these functions in the rustdoc (https://github.com/rust-lang/rust/pull/107926)
2024-02-13 12:06:25 +00:00
bors
e944a273ee Auto merge of #16547 - Veykril:proc-macro-literals, r=Veykril
fix: Validate literals in proc-macro-srv FreeFunctions::literal_from_str

cc https://github.com/rust-lang/rust-analyzer/pull/16446

meant to only get rid of some string allocs but then I noticed we can just implement this with the bare lexer.
2024-02-13 11:35:44 +00:00
Lukas Wirth
ed57008510 fix: Validate literals in proc-macro-srv FreeFunctions::literal_from_str 2024-02-13 12:33:51 +01:00
bors
925705e0c9 Auto merge of #16446 - Tyrubias:literal_from_str, r=Veykril
Implement `literal_from_str` for proc macro server

Closes #16233

Todos and unanswered questions:

- [x] Is this the correct approach? Can both the legacy and `rust_analyzer_span` servers depend on the `syntax` crate?
- [ ] How should we handle suffixes for string literals? It doesn't seem like `rust-analyzer` preservers suffix information after parsing.
- [x] Why are the `expect` tests failing? Specifically `test_fn_like_macro_clone_literals`
2024-02-13 10:41:36 +00:00
Mohammad Mustakim Ali
2c761048d4
fix: clippy 2024-02-13 10:11:17 +00:00
Victor Song
4923b8a74b Return Option<Parse<ast::Literal>> from ast::Literal::parse 2024-02-13 00:00:02 -06:00
Victor Song
1918f9b9e0 Address PR comments 2024-02-13 00:00:02 -06:00
Victor Song
cdb8a88ea3 Fix more compilation errors 2024-02-13 00:00:02 -06:00
Victor Song
965b14d17a Fix compilation errors 2024-02-13 00:00:02 -06:00
Victor Song
027f263ef5 Note FIXME for suffixes 2024-02-13 00:00:02 -06:00
Victor Song
6cd458f3d0 Move raw_delimiter_count to syntax crate 2024-02-13 00:00:02 -06:00
Victor Song
e8c9ca2a2f Refactor shared literal_from_str code 2024-02-13 00:00:02 -06:00
Victor Song
adf7adf3e8 Add syntax crate as proc-macro-srv dep 2024-02-13 00:00:02 -06:00
Victor Song
68365513f3 Implement literal_from_str for proc macro srv 2024-02-13 00:00:02 -06:00
bors
a9800004cb Auto merge of #16546 - odysa:minor/remove-eprintln, r=lnicola
minor: remove eprintln! macro

`stdx::eprintln!` was remove in #16465
2024-02-13 05:53:59 +00:00
Chengxu Bian
ca64359945 remove eprintln! overwrite 2024-02-12 23:54:32 -05:00
Davis Vaughan
45e05abf7b Activate on top level Cargo.toml and rust-project.json files 2024-02-12 18:14:10 -05:00
Mohammad Mustakim Ali
0af14ef8c3 chore: optimise 2024-02-12 23:11:06 +00:00
Mohammad Mustakim Ali
24a3c42bd6 feat: completion list suggests constructor like & builder methods first 2024-02-12 22:34:59 +00:00
bors
3770f73bd6 Auto merge of #16545 - Veykril:fix-target-layout-fetch, r=Veykril
fix: Fix target layout fetching

https://github.com/rust-lang/rust-analyzer/pull/16537 broke this, as `cargo rustc` cannot run against a virtual workspace, so it will always fail in such projects (like rust-analyzer itself). This brings back the plain rustc fallback,
2024-02-12 20:34:59 +00:00
Lukas Wirth
a7641a8f57 fix: Fix target layout fetching 2024-02-12 21:29:52 +01:00
dfireBird
0209c28136
add completions to show only traits in trait impl statement 2024-02-12 22:56:03 +05:30
bors
cf8733353d Auto merge of #16540 - Veykril:macro-arg, r=Veykril
internal: macro_arg query always returns a TokenTree
2024-02-12 16:32:40 +00:00
Lukas Wirth
2fa57d90bc internal: macro_arg query always returns a TokenTree 2024-02-12 17:19:41 +01:00
bors
35b0d66875 Auto merge of #16541 - Veykril:highlight-rustdoc, r=Veykril
Highlight rustdoc

Updated version of https://github.com/rust-lang/rust-analyzer/pull/16340
2024-02-12 15:20:33 +00:00
Lukas Wirth
c6bb35269c Remove autoclosing pair <> in rustdoc 2024-02-12 16:01:14 +01:00
bors
1811210339 Auto merge of #15476 - Wilfred:implement-saved-file3, r=Veykril
Substitute $saved_file in custom check commands

If the custom command has a $saved_file placeholder, and we know the file being saved, replace the placeholder and run a check command.

If there's a placeholder and we don't know the saved file, do nothing.

This is a simplified version of #15381, which I hope is easier to review.
2024-02-12 14:59:37 +00:00
Lukas Wirth
d24db9f2c3 Run npm run format 2024-02-12 15:58:17 +01:00
bors
818c30c311 Auto merge of #16092 - kilpkonn:term_search_1, r=Veykril
feat: Introduce term search to rust-analyzer

# Introduce term search to `rust-analyzer`
_I've marked this as draft as there might be some shortcomings, please point them out so I can fix them. Otherwise I think it is kind of ready as I think I'll rather introduce extra functionality in follow up PRs._

Term search (or I guess expression search for rust) is a technique to generate code by basically making the types match.
Consider the following program
```rust
fn wrap(arg: i32) -> Option<i32> {
    todo!();
}
```
From the types of values in scope and constructors of `Option`, we can produce the expected result of wrapping the argument in `Option`

Dependently typed languages such as `Idris2` and `Agda` have similar tools to help with proofs, but this can be also used in everyday development as a "auto-complete".

# Demo videos

https://github.com/rust-lang/rust-analyzer/assets/19900308/7b68a1b7-7dba-4e31-9221-6c7485e77d88

https://github.com/rust-lang/rust-analyzer/assets/19900308/0fae530a-aabb-4b28-af71-e19f8d3d64b2

# What does it currently do
- It works well with locals, free functions, type constructors and non-static impl methods that take items by value.
- Works with functions/methods that take shared references, but not with unique references (very conservative).
- Can handle projections to struct fields (eg. `foo.bar.baz`) but this might me more conservative than it has to be to avoid conflicting with borrow checker
- Should create only valid programs (no type / borrow checking errors). Tested with `rust-analyzer analysis-stats /path/to/ripgrep/Cargo.toml --run-term-search --validate-term-search` (basically running `cargo check` on all of the generated programs and only error seems to be due to type inference which is more of issue of testing method.

# Performace / fitness
```txt
ripgrep (latest)
Tail Expr syntactic hits: 130/1692 (7%)
Tail Exprs found: 523/1692 (30%)
Term search avg time: 9ms
Term search:         15.64s, 97ginstr, 8mb

rust-analyzer (on this branch)
Tail Expr syntactic hits: 804/13860 (5%)
Tail Exprs found: 6757/13860 (48%)
Term search avg time: 78ms
Term search:         1088.23s, 6765ginstr, 98mb
```
Highly generic code seems to blow up the search space so currently the amount of generics allowed is functions/methods is limited down to 0 (1 didn't give much improvement and 2 is already like 0.5+s search time)

# Plans for the future (not in this PR)
- ``~~Add impl methods that do not take `self` type (should be quite straight forward)~~ Done
- Be smarter (aka less restrictive) about borrow checking - this seems quite hard but since the current approach is rather naive I think some easy improvement is available.
- ``~~See if it works as a autocomplete while typing~~ Done

_Feel free to ask questions / point of shortcoming either here or on Zulip, I'll be happy to address them. I'm doing this as part of my MSc thesis so I'll be working on it till summer anyway 😄_
2024-02-12 14:47:12 +00:00
Wilfred Hughes
cdbf54f4bd flycheck: initial implementation of $saved_file
If the custom command has a $saved_file placeholder, and we know the
file being saved, replace the placeholder and then run a check command.

If there's a placeholder and we don't know the saved file, do nothing.
2024-02-12 15:45:48 +01:00
bors
47b4dd7273 Auto merge of #15923 - tamasfe:feat/better-ignored-macros2, r=Veykril
feat: ignored and disabled macro expansion

Supersedes #15117, I was having some conflicts after a rebase and since I didn't remember much of it I started clean instead.

The end result is pretty much the same as the linked PR, but instead of proc macro lookups, I marked the expanders that explicitly cannot be expanded and we shouldn't even attempt to do so.

## Unresolved questions

- [ ] I introduced a `DISABLED_ID` next to `DUMMY_ID` in `hir-expand`'s `ProcMacroExpander`, that is effectively exactly the same thing with slightly different semantics, dummy macros are not (yet) expanded probably due to errors, while not expanding disabled macros is part of the usual flow. I'm not sure if it's the right way to handle this, I also thought of just adding a flag instead of replacing the macro ID, so that the disabled macro can still be expanded for any reason if needed.
2024-02-12 12:42:45 +00:00
Lukas Wirth
e2a985e93f Encode disabled proc-macros via boolean flag, not special Expander 2024-02-12 13:39:38 +01:00
tamasfe
ab50ec9863 fix(macros): no diagnostics for disabled macro 2024-02-12 12:50:44 +01:00
tamasfe
6d45afd8d8 feat: ignored and disabled macro expansion 2024-02-12 12:50:40 +01:00
bors
3c24189589 Auto merge of #16530 - Veykril:missing-lt, r=Veykril
fix: Fix macro transcriber emitting incorrect lifetime tokens

Fixes https://github.com/rust-lang/rust-analyzer/issues/16529
2024-02-12 11:38:56 +00:00
bors
5e1b09bb76 Auto merge of #16537 - Veykril:sysroot-tools, r=Veykril
internal: tool discovery prefers sysroot tools

Fixes https://github.com/rust-lang/rust-analyzer/issues/15927, Fixes https://github.com/rust-lang/rust-analyzer/issues/16523

After this PR we will look for `cargo` and `rustc` in the sysroot if it was succesfully loaded instead of using the current lookup scheme. This should be more correct than the current approach as that relies on the working directory of the server binary or loade workspace, meaning it can behave a bit odd wrt overrides.

Additionally, rust-project.json projects now get the target data layout set so there should be better const eval support now.
2024-02-12 11:26:53 +00:00
Lukas Wirth
8f3209ba27 internal: tool discovery prefers sysroot tools 2024-02-12 12:08:18 +01:00