by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 09:41
    recombinant closed #2220
  • 07:32
    Undin labeled #6161
  • 07:32
    Undin labeled #6161
  • 07:32
    Undin assigned #6161
  • 03:31
    drglove opened #6161
  • 03:22
    medakk opened #6160
  • Sep 25 17:49
    dima74 synchronize #6157
  • Sep 25 16:17
    github-actions[bot] milestoned #6159
  • Sep 25 16:16
    bors[bot] closed #6159
  • Sep 25 15:42
    bors[bot] closed #6071
  • Sep 25 15:42
    bors[bot] closed #6055
  • Sep 25 15:42
    bors[bot] closed #6096
  • Sep 25 15:42
    bors[bot] closed #6034
  • Sep 25 15:42
    bors[bot] closed #6058
  • Sep 25 15:34
    Undin labeled #6071
  • Sep 25 15:28
    Undin opened #6159
  • Sep 25 14:59
    mchernyavsky milestoned #6071
  • Sep 25 14:59
    mchernyavsky synchronize #6071
  • Sep 25 13:19
    bors[bot] closed #6156
  • Sep 25 11:53
    vlad20012 milestoned #6156
Ara Adkins
@iamrecursion
in one cargo workspace
Vlad Beskrovnyy
@vlad20012
A workspace should works fine
Ara Adkins
@iamrecursion
It seems to, for the most part!
I'm seeing some errors that don't occur during compilation, though
Vlad Beskrovnyy
@vlad20012
Intellij Rust has some false-positives, unfortunately(
Ara Adkins
@iamrecursion
Fair enough!
Vlad Beskrovnyy
@vlad20012
We just created a release branch release-126. The release is scheduled for 13.07.2020.
Ara Adkins
@iamrecursion
I'm having an issue where builds using cargo done through "Run Anything" are failing randomly with "crate not found for $foo"
When done in the shell it works absolutely fine
Ara Adkins
@iamrecursion
Vlad Beskrovnyy
@vlad20012
Thanks!
Evan Stoll
@evanjs

So I am trying to set some breakpoints on gtk-rs, which is a dependency on my project.
Currently, the breakpoints seem to be valid/recognized by the debugger (they are red), but do not suspend the program.

Note that I can step into these areas of execution just fine.
It's just that I can't have the debugger run until it hits a breakpoint in an external library.

Is suspending on breakpoints in external libraries supported?

Evan Stoll
@evanjs
rust-lldb seems to stop at the breakpoint just fine when run outside of CLion
Vlad Beskrovnyy
@vlad20012
@evanjs Could you please open an issue in out tracker? https://github.com/intellij-rust/intellij-rust/issues
Evan Stoll
@evanjs
@vlad20012 I always try to check first to make sure I’m not being dumb. Will do. Thanks!
Ara Adkins
@iamrecursion
I'm trying to launch a debugger for the first time, but I'm seeing "more than one binary was produced". Where do I set the flag it's mentioning?
Artem Mukhin
@ortem
@iamrecursion please try to specify the flag in the run configuration's command (you can open the configuration using Edit Configurations... button). See https://blog.jetbrains.com/clion/2019/10/debugging-rust-code-in-clion/ for more information and screenshots
Ara Adkins
@iamrecursion
I've no idea what the binary name would be.
The ones I expect don't seem to exist, which is very odd.
Artem Mukhin
@ortem
@iamrecursion Could you also try to delete this run configuration and create a new one by pressing the run button on the left of your main function in the editor?
Ara Adkins
@iamrecursion
Ah, got it working!
Now memory view in the debugger is showing up as blank.
Ah, fixed it. There was a hidden permissions dialogue from my OS
hah
Ara Adkins
@iamrecursion
Is there a way to change the asm syntax?
or is that just external
Artem Mukhin
@ortem
@iamrecursion Great! AFAIK only x86 AT&T syntax is supported now. The corresponding issue for Intel syntax: https://youtrack.jetbrains.com/issue/CPP-9009
matrixbot
@matrixbot
mouse008 Does this plugin look inside unsafe blocks, particularly those containing asm!(...)? I'm getting an (incorrect) "potentially uninitialized..." warning from IntelliJ. Both cargo check and cargo clippyare totally OK with that code - no complaint from them, so they must've understood what the code is doing.
Vlad Beskrovnyy
@vlad20012
I'd say it doesn't look into an asm macro
Jakub Beránek
@Kobzol
Hi! I have a contributor question. Currently I have 40 PRs opened. Most of them are waiting for a response from a maintainer to move forward. Sometimes I'm not sure if a PR is waiting to be reviewed in some backlog and I'm supposed to just wait or if the PR wasn't noticed by the maintainers and it will not be noticed until I ping someone. The longer a PR stays open, the more difficult it becomes to reintegrate it into master and sometimes it might also just get forgotten.
However, I don't want to bother/spam you with pings/mentions. So basically I'm interested in how can I recognize that the PR will eventually be looked at? Is it enough to include it in the To test project? Or must the PR also have someone assigned?
Vlad Beskrovnyy
@vlad20012

Oh :(
It's bad if the PR is not assigned to anyone. It can be easily missed. You can assign it to a someone by yourself.

If PR is assigned, but the assignee doesn't respond for a long time, I think it's OK to ping them.

Ideally, PRs should be reviewed fast. But I don't know how to achieve it :(

I can speak for myself: I usually focus on some large task for a long time and it's hard for me to switch context and review something in a subsystem that I am not good at. So, sometimes I review some PRs "in batch" =D At that time I don't do anything large. Maybe some bugfixes...

I'm sorry that sometimes you have to wait for my review for a long time :(
Jakub Beránek
@Kobzol
No worries! I'm glad for all of your reviews and feedback :) I was mostly concerned about PRs that might have gotten forgotten. I'll try to tentatively assign some of the PRs or ping in case where I think that it might be "forgotten" :) Thanks.
Vlad Beskrovnyy
@vlad20012
Thank you for your contribution!
Evan Stoll
@evanjs
Is there any way to provide IntelliJ Rust with a path to the stdlib and etc via ENV variables or etc?
I am using lorri, which will automatically update my toolchains and etc (as I am also using the nixpkgs-mozilla overlay), but since I am not using rustup, I have to set the stdlib path every time my toolchain is updated
Vlad Beskrovnyy
@vlad20012
Hmm, unfortunately, no.
Skye Im
@skairunner

I'm using Mac. For some reason hitting "Debug" on a project that uses proj causes it to go

dyld: Library not loaded: @rpath/libproj.20.dylib
  Referenced from: /Users/sky/myproject/target/debug/deps/my_tests-a84efe702241bb00
  Reason: image not found
Signal: SIGABRT (signal SIGABRT)

The problem is that using brew install proj only provides libproj.19.dylib, and I don't think libproj.20.dylib even exists. I've also tried installing from the head of proj to no avail. How would I go about pointing the Rust plugin to use libproj.19 instead?

Matyáš Racek
@panstromek
So I have been stressing the refactoring subsystem quite a lot lately (I guess you noticed :D ) and one problem I can't get a hang on is how "extract function " decides which parameters to pass by value and which ones by reference.
It doesn't seem to make much sense, there is often a situation with say 5 i32 parameters, all of them are just read from , no assignments and after extracting the function, some of them are passed by value and some by reference
I also have similar problems with pointers.
also, often the usages in the extracted function are not updated (when changed from by-value access to by-ref access)
I'll post an issue when I find some minimal example, but so far it only happened when extracting something complicated, so I can't really infer what's the rule behind this
Is there some simple logic behind it that I can't see?
Jakub Beránek
@Kobzol
the heuristic is relatively complicated, it depends on many things (if the parameter is used after the extracted block, if it is a reference, if there are some things referring to it, it it is mutable etc.). it could probably be improved
Ara Adkins
@iamrecursion
When debug printing a character literal that has an escape-code representation (such as \n), a standard terminal will display this as the escape code. When running the same test in IntelliJ's test runner window, it instead prints it as a literal newline, rather than the escape code.
Is this a bug or something I can configure somewhere?
In terminal:
[EnsoLexer.Flexer] Enter State: IDENT_SFX_CHECK
    [EnsoLexer.Flexer] Current character is Ok('\n').
In the test runner window:
[EnsoLexer.Flexer] Enter State: IDENT_SFX_CHECK
    [EnsoLexer.Flexer] Current character is Ok('
').
Ara Adkins
@iamrecursion
Jakub Beránek
@Kobzol
I started writing a blog series describing my contributions to this plugin - https://www.reddit.com/r/rust/comments/ifxr99/contributing_to_the_intellijrust_plugin_a_series/. Let me know if you find any mistakes :)