The work has started: https://github.com/intellij-rust/intellij-rust/tree/fc2cfb8e0fc76984495a34ae6a83cbb37188c699/debugger

State of the art

The debugger is officially available in CLion since 2018.1. Note, CLion doesn't support debugging with msvc toolchains, so if you are using Windows, you need:

• install gnu rust toolchain (rustup install stable-gnu)
• setup gnu (Cygwin or MinGW) toolchains in CLion (Preferences > Build, Execution, Deployment > Toolchains).

To debug you just need to:

• Run debug command via gutter icon
• Or create Cargo Command run configurtion

To everyone who has contributed code to IntelliJ Rust: we want to make this plugin officially supported by Jet Brains, but to do so, we need contributor license agreements signed by anyone who had added code to the plugin. If you do not wish to sign such a CLA form, let me know so that I can find a way to back out any changes you may have made.

To sign the CLA, please follow instructions at https://www.jetbrains.com/agreements/cla/. The procedure consists of a couple clicks: no need to scan or print or snail-mail anything. Comment on this issue after signing the CLA so that I can track progress easily.

The text of CLA can also be found here.

It's quite possible that due to recent code rewrites, your change may not appear anymore. If that is the case, I only ask that you verify this, so I can take you off of the list of people we need CLAs from.

Thank you all!

Q&A:

Q: Does this mean that IntelliJ Rust is becoming a closed source proprietary project of Jet Brains?

A: No, IntelliJ Rust plugin will be free, open source and welcoming to contributors. However it is possible that in the future Jet Brains releases a paid product based on the IntelliJ Rust technology.

Q: What is the purpose of CLA?

A: This CLA is for your protection as a Contributor as well as the protection of JetBrains and its users; it does not change your rights to use your own Contributions for any other purpose.

cc:

• [x] @alexeykudinkin
• [x] @alexpana
• [x] @allengeorge
• [x] @alobb
• [x] @alygin
• [x] @andruhon
• [x] @ashleysommer
• [x] @bgourlie
• [x] @CGavrila
• [x] @chriskrycho
• [x] @contradictioned
• [x] @d9n
• [x] @daschl
• [x] @Falkenfighter
• [x] @farodin91
• [x] @framlog
• [x] @friedroman
• [x] @greg-kargin
• [x] @himikof
• [x] @HybridEidolon
• [x] @johnthagen
• [x] @jonas-schievink
• [x] @KalitaAlexey
• [x] @Keats
• [x] @kumbayo
• [x] @la10736
• [x] @LiamClark
• [x] @Litarvan
• [x] @madisp
• [x] @mbStavola
• [x] @mcarlin
• [x] @mfarrugi
• [x] @mitchhentges
• [x] @mkaput
• [x] @mrhota
• [x] @netvl
• [x] @ninjabear
• [x] @oistein
• [x] @pavel-v-chernykh
• [x] @Shiroy
• [x] @sirgl
• [x] @slavam2605
• [x] @ThoseGrapefruits
• [x] @tigarmo
• [x] @tov
• [x] @Turbo87
• [x] @Undin
• [x] @vasily-kirichenko
• [x] @winger
• [x] @zjhmale

Issue template take from https://github.com/jwiegley/use-package/issues/282 :)

Hi. I'm trying to figure out how to use rustc & cargo from my WSL, where I installed rust, and works perfectly. In fact, I don't want to install Rust on Windows.

https://medium.com/@bgourlie/cross-platform-development-on-windows-is-suddenly-awesome-da863a28fa1e

For example, let's say I am using the crate derive_builder with the following code snippet:

#[derive(Clone, Debug, Builder)]
pub struct MyStruct {
    foo: String
}

derive_builder generates a new struct named MyStructBuilder. I'd like to have this generated MyStructBuilder struct available as an autocomplete option to make its usage easier.

Resolve all symlinks in packages and targets.

Also, resolve symlinks before any call of LightDirectoryIndex to use the same virtual files as we use while index creation

Should fix #2466, but I don't know how to create good tests for this case Fixes #2633

Environment

• IntelliJ Rust plugin version: Release 127 -- also tried 0.3.128.3262-202-nightly
• Rust toolchain version: 1.45
• IDE name and version: IntelliJ Community 2020.2 (was also the case on 2020.1)
• Operating system: Kubuntu Linux 19.10

Problem description

After updating the plugin from 126 -> 127 my project had lots of various errors. I have tried reimporting the project, re-loading the Cargo.toml from the "Cargo" menu. In Release 126, I was using the "experimental macro engine" and I didn't have any errors across my project.

I don't really understand which of the following is a root problem, so I will just post some of the issues to give a picture of what I'm experiencing.

Edition is not being correctly detected and async keyword is disallowed

"This feature is only available in Edition 2018"

Source files are not being included in the module tree

"File is not included in module tree"

Modules declared at the top level are not found

"File not found for module"

see first screenshot

The one thing that makes this project different is that it is using rust-protobuf to do codegen and is including the generated code at the top of main. This means the project not only has a build.rs, but also an include! macro in main.rs.

I downgraded the plugin to 126 in 2020.1 and the project started building properly again. I can't use plugin 126 in 2020.2. Is there a way I can get a build (or build myself) a version of 126 that I can use in 2020.2 while we work this out?

I did try suggestions in #3628 and #4907, but have not been able to find a resolution.

Thanks for your help, and thanks for an awesome plugin. :)

Steps to reproduce

Source code for project is not open source, so this may be difficult.

This PR changes match postfix template to generate all match arms instead of just a single wildcard.

Currently, no template is used, the caret is just moved after the left brace of the first arm. Should there be some template to rename things from the generated arms? If yes, what should it rename?

Fixes https://github.com/intellij-rust/intellij-rust/issues/6630 Fixes https://github.com/intellij-rust/intellij-rust/issues/4727

changelog: match postfix template now generates all missing match arms by default.

This PR extends Implement members functionality.

1. Added automatic implementation of type aliases (with defaulting type ())
2. Implement members quick fix now shows a chooser dialog to choose members to implement
3. Ctrl+I (implement members code insight feature) is now available

Example of chooser dialog:

Example (when all members were chosen):

#![feature(associated_type_defaults)]

trait Foo {
    type Type1 = i32;
    type Type2;
    type Type3;
    fn foo();
    fn bar();
    fn baz() {}
}

struct Bar;

impl Foo for Bar {
    type Type2 = ();
    type Type3 = ();

    fn foo() {
        unimplemented!()
    }

    fn bar() {
        unimplemented!()
    }
}

Note: I commented out one test, because now quick fix does not automatically generate all members, only after dialog choosing. I don't know how to write a new version of test.

This PR adds the Change signature refactoring.

The current implementation has basic functionality.

• ~How should the user be able to enter the name and type of parameters? I suggest that we use RsPat for name and Ty or RsTypeReference for types instead of plain strings, so that after the user enters something, we try to parse it and if it fails, we will not allow the dialog to proceed.~
• ~Currently, if a new parameter is added, it will not be filled with a default value at call sites, so that the user will not forget to update the call sites. This mirrors the behaviour of Kotlin.~
• ~Should the dialog offer things like async, unsafe, extern or variadic args? If yes, we need to let the user enter any possible value for these attributes. I think that it's worth to do it only if we can actually refactor something after changing them. Maybe removing/adding await/unsafe from call sites?~
• ~Originally I wanted to unify the Change signature and Extract function UI (and some data structures), but I realized that they actually differ quite a lot and it would complicate the code too much I think. I checked the Kotlin plugin and it has two different dialogs for these refactorings, so I think that it's ok.~
• ~I wanted to move all surrounding whitespace and comments when a parameter is moved from one place to another, but I'm having a difficulty making it work. The commented code in insertItemWithComma didn't work, basically if I try to do something like this:~

val inserted = parent.addBefore(<some whitespace>, anchor)

~the inserted will contain anchor instead of the inserted whitespace. This breaks copying of successive whitespace and comment elements, which I tried to do in a loop. Any hints of what might be wrong here?~

I'm not a huge fan of the signature config being mutable, but it makes UI and test code simpler and it also helps with detection of modified parameters (so I don't have to generate a GUID or something like that for them).

~The logic about detecting moved/removed/added parameters is slightly convoluted, it could be probably simplified, but I want to leave that for a final refactoring. It's not as simple as it sounds, as we must detect what parameters were removed, what were added and what were just moved, these operations have different semantics, even if they end up with the same result in the signature (see test move and add parameter and test swap parameters).~

Fixes: https://github.com/intellij-rust/intellij-rust/issues/4927

changelog: Add the Change Signature refactoring for functions and methods.

This PR adds a quick fix that lets the user add new function parameters to a function from a function call, using the new Change signature refactoring. So far it only works for function and method calls and not tuple struct constructors. The behaviour of the fix is heavily inspired by a similar fix in the Kotlin plugin.

There are two TODOs in the code, which I'm not sure how to resolve:

• How to name parameters? p0, p1, etc.? Or continue counting from the existing parameter count? Also the fix should probably make sure that it doesn't generate collisions in parameter binding names.
• How to get the correct type reference from the argument expression type? That is especially important for import to work. I tried to use a type reference fragment, that sort-of works, but it imports the type with a wrong path. I need to somehow get from Ty to RsTypeReference that exists in the context of the target function.

Related issue: https://github.com/intellij-rust/intellij-rust/issues/6744 Fixes: https://github.com/intellij-rust/intellij-rust/issues/3582

changelog: Add quick fix to add a parameter to a function from a function call.

Currently it replaces function parameters with the function arguments. Still need to make sure arguments will be resolved in the same order were they not inlined by creating variables for them before the main inline. Here's a Kotlin example: That's the original file. We'll inline foo()

var count = 1
private fun main() {
    val a = foo(bar())
}

private fun foo(number: Int): Int {
    return number * bar() + number
}

private fun bar(): Int {
    return count++
}

The original code should get 2 * 3 + 2 inside foo. My code currently inlines the values directly, like so:

var count = 1
private fun main() {
    val a = bar() * bar() + bar()
}

    private fun bar(): Int {
    return count++
}

Which leads the calculation to be 2 * 3 + 4, because the function will be called an additional time. The correct inline (as shown by Kotlin) is:

var count = 1
private fun main() {
    val number = bar()
    val a = number * bar() + number
}

    private fun bar(): Int {
    return count++
}

Which makes sure number has a single value, assined before any calls for bar() happening inside foo().

Environment

• IntelliJ Rust plugin version: 0.4.185.5086-223
• Rust toolchain version: 1.67.0-nightly
• IDE name and version: CLion 2022.3
• Operating system: Arch rolling

Problem description

With the unstable try_blocks feature, I just take the demonstration code from https://github.com/rust-lang/rust-analyzer/pull/13856, and it doesn't work.

Steps to reproduce

#![feature(try_blocks)]

fn main() {
    let r = try { 1_u32 };
    match r {
        Ok(a) => (),
        Err(()) => (),
    };
}

The pre-requisite for injection availability is the macro must accept a TokenStream.

This will allow IntelliLang to automatically propose injection of different languages. A typical use case might be injecting the Pomsky language to which I'm adding support in IDEA.

At the moment I'm implementing my own injection, which is a lot of work.
So if we can have it in the language itself, it's better.

cc @Aloso

This plugin has everything I need and more. However there is one thing I really miss - The wonderful Flowistry plugin in Visual Studio and can't seem to find anything similar in Jetbrains. I keep going back to Visual Studio just to use this highlighter. I wish there was something similar for Rust. This will truly make Jetbrains the goto IDE for me.

Environment

• IntelliJ Rust plugin version: 0.4.185.5086-223
• Rust toolchain version: 1.63.0 (4b91a6ea7 2022-08-08) x86_64-pc-windows-msvc
• IDE name and version: CLion 2022.3.1 (CL-223.8214.51)
• Operating system: Windows 10 10.0
• Macro expansion: enabled

Problem description

"Introduce variable" or "Introduce parameter" is not able to extract a parameter from a function call if that parameter is a constant.

Steps to reproduce

Example code:

fn get_thing(x: &str) -> Option<String> {
	return None;
}

const CONSTANT_STR: &'static str = "ABC";

fn test() {
	get_thing("abc");
	get_thing(CONSTANT_STR);
}

If I place caret inside "abc" and use Introduce Parameter, it correctly suggests "abc" as an option:

If I place caret inside CONSTANT_STR, it immediately extracts the whole function call:

IntelliJ IDEA 2022.3.1 (Ultimate Edition) Build #IU-223.8214.52, built on December 20, 2022 Runtime version: 17.0.5+1-b653.23 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. Windows 11 10.0 GC: G1 Young Generation, G1 Old Generation Memory: 4096M Cores: 8

Non-Bundled Plugins: org.rust.lang (0.4.185.5086-223)

Problem description

Please check the options in Rust Color scheme - 2 values constantly switch (after syncing options from another JetBrains IDE like WebStorm) to default colors instead of inheriting values from options in the General and Language Defaults color sections (please check the screenshots), looks like their setup differs from the other options, what causes this bug. I have to always switch these options' values manually, which is not comfortable.

These options are:

Functions - Function call Functions - Method call

All other colors in Rust section don't change unexpectedly and work fine.

Actually, the bug is pretty the same as here (if that could help in any way): https://youtrack.jetbrains.com/issue/PY-58264/Python-colors-dont-inherit-properly

Environment

Steps to reproduce

Looks like the bug is with Setting Sync option but I'm not 100% sure.

How to reproduce:

• I have Settings Sync turned on in WebStorm and IntelliJ.
• I opened WebStorm and changed the color of Color Scheme - Language Defaults - Predefined symbol.
• Then I closed WebStorm and opened IntelliJ. Then opened Rust section in Color Scheme, and those 2 options are not inherited again.