Commit graph

9859 commits

Author SHA1 Message Date
veetaha
9a82ee0de2 Fix "show syntax tree" command
@matlkad please don't forget to keep it up-to-date!
2020-05-10 20:43:48 +03:00
veetaha
2af6b4b67e Correct use cannot have type args as per flodiebold 2020-05-10 20:23:29 +03:00
veetaha
a19b164661 Correct path docs and add colon2 token to Path ast node 2020-05-10 20:21:46 +03:00
veetaha
eedf11ae88 Add example with const in TypeBound as per flodiebold 2020-05-10 19:24:06 +03:00
veetaha
5707c2d7a6 Remove todo comment about arg vs param difference as per clarification from flodiebold 2020-05-10 19:19:56 +03:00
veetaha
09c438b47e Properly document const impl as per flodiebold 2020-05-10 19:17:46 +03:00
veetaha
80c529d1dc Remove on TypeAliasDef as per flodiebold 2020-05-10 19:15:04 +03:00
veetaha
7a49165f5d Remove MacroStmts as per edwin0cheng 2020-05-10 19:11:22 +03:00
veetaha
258a3461b4 Add proper docs for TokenTree as per edwin0cheng 2020-05-10 19:09:36 +03:00
veetaha
3554866d67 Run codegen of ast types with documentation 2020-05-10 19:06:28 +03:00
veetaha
e0e384a34a Add ast docs to codegen script 2020-05-10 19:05:51 +03:00
bors[bot]
225f353aa2
Merge #4412
4412: infer: Make expected rhs type for plain assign the lhs type r=flodiebold a=kiljacken

This fixes an issue where the following code sample would fail to infer
the type contained in the option:
```rust
fn main() {
    let mut end = None; // Was Option<{unknown}>, is now Option<bool>
    loop {
        end = Some(true);
    }
}
```

Co-authored-by: Emil Lauridsen <mine809@gmail.com>
2020-05-10 14:48:04 +00:00
Emil Lauridsen
85d44cad45 infer: Make expected rhs type for plain assign the lhs type
This fixes an issue where the following code sample would fail to infer
the type contained in the option:
```rust
fn main() {
    let mut end = None; // TODO: Fix inference for this in RA
    loop {
        end = Some(true);
    }
}
```
2020-05-10 16:24:04 +02:00
bors[bot]
4578154b60
Merge #4409
4409: Hot fix panic for function_signature r=edwin0cheng a=edwin0cheng

I am totally agree this comment: 

f1cb5b8a29/crates/ra_ide/src/display/function_signature.rs (L3-L4)

But let hot fix all panic for right now, it is so disturbing when browsing code...


Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2020-05-10 10:04:44 +00:00
Edwin Cheng
a3375c1a88 Remove dbg 2020-05-10 18:03:44 +08:00
Edwin Cheng
9405116d51 Hot fix panic for function_signature 2020-05-10 16:27:31 +08:00
bors[bot]
f1cb5b8a29
Merge #4392
4392: Add From should not move the cursor r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-09 14:22:06 +00:00
Aleksey Kladov
d9828a57fc Add From should not move the cursor 2020-05-09 16:21:10 +02:00
bors[bot]
77d2eaba16
Merge #4389
4389: Ascribe more correct types r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-09 13:58:22 +00:00
Aleksey Kladov
e201e7834d Ascribe more correct types 2020-05-09 15:57:53 +02:00
bors[bot]
c5c07c2a0a
Merge #4388
4388: unindent -> dedent r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-09 12:49:18 +00:00
Aleksey Kladov
5c04d8544c unindent -> dedent 2020-05-09 14:48:43 +02:00
bors[bot]
5af66e5486
Merge #4387
4387: More fluent indent API r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-09 12:40:45 +00:00
Aleksey Kladov
231fddab54 More fluent indent API 2020-05-09 14:40:11 +02:00
Aleksey Kladov
c6334285e3 Fix visibility 2020-05-09 13:59:25 +02:00
bors[bot]
25e37e2c93
Merge #4175
4175: Introduce HirDisplay method for rendering source code & use it in add_function assist r=flodiebold a=TimoFreiberg

Next feature for #3639.

So far the only change in the new `HirDisplay` method is that paths are qualified, but more changes will be necessary (omitting the function name from function types, returning an error instead of printing `"{unknown}"`, probably more).

Is that approach okay?

Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
2020-05-09 09:29:11 +00:00
bors[bot]
d7a0b0ff91
Merge #4381
4381: Simplify r=matklad a=Veetaha



Co-authored-by: veetaha <veetaha2@gmail.com>
2020-05-09 08:42:24 +00:00
veetaha
e83a2912b8 Simpify project discovery 2020-05-09 02:51:59 +03:00
veetaha
aca9aa8b7e Simplify 2020-05-09 02:27:44 +03:00
bors[bot]
1acb556907
Merge #4379
4379: Handle coercing function types to function pointers in match r=matklad a=flodiebold

E.g. in
```rust
match x {
    1 => function1,
    2 => function2,
}
```
we need to try coercing both to pointers. Turns out this is a special case in
rustc as well (see the link in the comment).

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2020-05-08 20:37:14 +00:00
Florian Diebold
a3d866e776 Handle coercing function types to function pointers in match
E.g. in
```rust
match x {
    1 => function1,
    2 => function2,
}
```
we need to try coercing both to pointers. Turns out this is a special case in
rustc as well (see the link in the comment).
2020-05-08 22:14:01 +02:00
bors[bot]
f9ec7cebef
Merge #4377
4377: Implement better handling of divergence r=matklad a=flodiebold

Divergence here means that for some reason, the end of a block will not be reached. We tried to model this just using the never type, but that doesn't work fully (e.g. in `let x = { loop {}; "foo" };` x should still have type `&str`); so this introduces a `diverges` flag that the type checker keeps track of, like rustc does. We also add some checking for `break`, but no support for break-with-value or labeled breaks yet.

Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2020-05-08 18:09:25 +00:00
Florian Diebold
d0129c4ddb Add diagnostic for break outside of loop 2020-05-08 19:48:03 +02:00
Florian Diebold
f8bf94a4b9 Use matches! 2020-05-08 19:30:02 +02:00
bors[bot]
f1fa9aa4c4
Merge #4366
4366: Unified debug lens r=matklad a=vsrs

Right now every debug engine gets the debug executable and exports the errors on its own.

This PR unifies the way all engines work. And adds an option to configure each engine separably.
For example, this adds visualizers for both `CodeLLDB` and `C++ tools Windows debugger`
```json
"rust-analyzer.debug.engineSettings": {
    "cppvsdbg": {
        "visualizerFile": "${workspaceRoot}/rdisk.natvis"
    },
    "lldb": {
        "initCommands": [
            "command script import ${workspaceRoot}/rdisk.vis.py"
        ]
    }
}
```

Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: vsrs <62505555+vsrs@users.noreply.github.com>
2020-05-08 17:19:02 +00:00
bors[bot]
d81e19286f
Merge #4378
4378: Add stderr to error message r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-08 16:54:38 +00:00
Aleksey Kladov
f739e0119c Add stderr to error message 2020-05-08 18:53:53 +02:00
vsrs
0ef17ef1ee Merge remote-tracking branch 'upstream/master' into uniformed_debug_lens
# Conflicts:
#	editors/code/src/commands/runnables.ts
2020-05-08 19:34:34 +03:00
Florian Diebold
b60970fd20 Handle break somewhat better
Still no break-with-value or labels, but at least we know that `loop { break; }`
doesn't diverge.
2020-05-08 18:28:01 +02:00
vsrs
1be6320ea6
"rust-analyzer.debug.openDebugPane"
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
2020-05-08 19:22:26 +03:00
Florian Diebold
fe7bf993aa Implement better handling of divergence
Divergence here means that for some reason, the end of a block will not be
reached. We tried to model this just using the never type, but that doesn't work
fully (e.g. in `let x = { loop {}; "foo" };` x should still have type `&str`);
so this introduces a `diverges` flag that the type checker keeps track of, like
rustc does.
2020-05-08 18:15:24 +02:00
Timo Freiberg
64e6b8200b Use new HirDisplay variant in add_function assist 2020-05-08 17:14:45 +02:00
Timo Freiberg
fe93675e8a New HirDisplay method for displaying sourcecode 2020-05-08 17:12:18 +02:00
bors[bot]
d3eb9d8eaf
Merge #4376
4376: Fix type of byte literals r=matklad a=flodiebold

They're `&[u8; N]`, not `&[u8]` (see #4374).

Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
2020-05-08 13:22:05 +00:00
Florian Diebold
f5177f91ae Fix type of byte literals
They're `&[u8; N]`, not `&[u8]` (see #4374).
2020-05-08 15:18:33 +02:00
bors[bot]
51e4b92c1e
Merge #4375
4375: Cleanup toolchain handling r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-05-08 12:55:55 +00:00
Aleksey Kladov
ecff5dc141 Cleanup 2020-05-08 14:55:28 +02:00
Aleksey Kladov
7c0409e0c7 Cleanup 2020-05-08 12:34:39 +02:00
Aleksey Kladov
6713be0b13 Rename ra_env -> ra_toolchain 2020-05-08 12:25:36 +02:00
bors[bot]
8295a9340c
Merge #4329
4329: Look for `cargo`, `rustc`, and `rustup` in standard installation path r=matklad a=cdisselkoen

Discussed in #3118.  This is approximately a 90% fix for the issue described there.

This PR creates a new crate `ra_env` with a function `get_path_for_executable()`; see docs there.  `get_path_for_executable()` improves and generalizes the function `cargo_binary()` which was previously duplicated in the `ra_project_model` and `ra_flycheck` crates.  (Both of those crates now depend on the new `ra_env` crate.)  The new function checks (e.g.) `$CARGO` and `$PATH`, but also falls back on `~/.cargo/bin` manually before erroring out.  This should allow most users to not have to worry about setting the `$CARGO` or `$PATH` variables for VSCode, which can be difficult e.g. on macOS as discussed in #3118.

I've attempted to replace all calls to `cargo`, `rustc`, and `rustup` in rust-analyzer with appropriate invocations of `get_path_for_executable()`; I don't think I've missed any in Rust code, but there is at least one invocation in TypeScript code which I haven't fixed.  (I'm not sure whether it's affected by the same problem or not.) a4778ddb7a/editors/code/src/cargo.ts (L79)

I'm sure this PR could be improved a bunch, so I'm happy to take feedback/suggestions on how to solve this problem better, or just bikeshedding variable/function/crate names etc.

cc @Veetaha 

Fixes #3118.

Co-authored-by: Craig Disselkoen <craigdissel@gmail.com>
Co-authored-by: veetaha <veetaha2@gmail.com>
2020-05-08 10:11:19 +00:00