I have a project set up that builds fine with cargo build, but when I open it in Emacs with rust-mode and racer-mode it gives the the error can't find crate for whatever_dependency for every single extern crate whatever_dependency; declaration. I assume this means that Racer is not finding my dependencies, so I was wondering if there's anything I need to do to tell Racer where to find them?
I've set CARGO_HOME to /home/myUser/.cargo, but that doesn't seem to help.
Okay, I was being stupid: it wasn't actually emacs-racer producing the error, it was flycheck mode. It's fixable by installing rust-flycheck.
Related
I'm getting started with Haskell and VSCode. I've forked and downloaded a repo with Haskell code. I've followed instructions for setting up a nix-shell correctly for this repo. I can successfully invoke cabal build and haskell-language-server for week 1 examples.
I've started up VSCode from within nix-shell and I can see that the language server is reporting symbol information to VSCode. For example:
However, I often find that if I try to Go To Definition VSCode reports that no definition is found:
For many of these symbols I find that if I hover my cursor over the symbol I'm shown where the symbol is defined:
Othertimes, I find that Go To Definition correctly resolves. For example, AuctionSchema on this line resolves correctly, while AuctionSchema on this line does not.
Why does Go To Definition only sometimes work? Is there a way to fix this?
I use emacs within NixOS, and I find that definitions are only found when they’re within the project I’m working on. Sometimes if I’m in src and the definition is in lib it won’t find it either. I just assumed that Haskell Language Server cannot use Cabal or Hpack to find definitions, but only follows types within the directory branch the current source resides. Yep, that’s annoying, but it seems to be what’s currently on offer.
This is a long post, sorry.
I have been trying to start a project, using Rust, but ran into a problem: it just does not work correctly on Linux in VSCode/Atom.
Wasted 3 days, searching online, trying different tutorials/videos - nothing worked + most of the material is from 2017. I have tried Matrix chat, but no one knew what to do. Git too has no solution as people keep suggesting very random things, like "change this variable in toml file to something else, and back again"
Git: https://github.com/rust-lang/rls-vscode/issues/513
I installed (and re-installed rust many times in the last 3 days), and it works just fine from the terminal, but not in the Editor.
Two Issues:
Editors don't see any crates, so you can't run your code from the editor.
Autocomplete does not work (only works on std, not on extra crates you add).
What I did (out of many other things):
install Rust (on Manjaro and Debian computers): curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Tried stable, beta, nightly (for racer)
Just did a clean install again:
stable installed - rustc 1.40.0 (73528e339 2019-12-16)
Rust is installed now. Great!
Installed Rust (rls) rust-lang.rust extension in VSCode (and rust in Atom)
Created a new project: cargo new test_proj and added new rand = "0.6" to [dependencies] and used cargo build. It did build rand
Added "rust-client.enableMultiProjectSetup": true to the settings file to avoid a warning: A Cargo.toml file must be at the root of the workspace in order to support all features. Alternatively set rust-client.enableMultiProjectSetup=true in settings. by Rust (rls)
I also install 'code runner' extension that I use with Python, C++, and Java, to run the code from within the editor.
So now I have just the main func and it runs just fine from the editor:
Now I add rand and it seems to work, and does SOME auto-completion...
But now it stops working:
OK, I will finish the code and try running it, And now we can't run it anymore as the crate is missing:
OK, let's try Ctrl + Shift + B and try cargo build:
For some odd reason, it is looking in /media/Work/Work/rust_code and not in /media/Work/Work/rust_code/test_proj/
One last thing: let's try running in the terminal:
So it does work just fine.
Sorry for the long post, but I have wasted 3 days now and it still can't get it up and running. Did anyone manage to set this up at all?
It has to be Atom or VSCode as I have all of the other languages/projects setup there + VSCode is listed on the official Rust website, so I presume it should work.
Basically, out of two editors (VSCode and Atom), that have Debugging capabilities, unlike Intellij Rust, both don't work for me and I just can't code in Rust as tools are literally broken/not mature enough for productive work. Please let me know if I am wrong and it is just a case of one little flag, that everyone forgets to mention, is missing in some config.
Short Version
Assuming I understand the issue correctly. Then the various build issues boil down to different ways you're trying to build the project, and attempting to do so in different directories.
TL;DR: The directory you have open in VSCode is the rust_code directory. Close it and instead open rust_code/test_proj. Now the Rust: cargo build (or Rust: cargo run) should work.
Long Version
Editors don't see any crates, so you can't run your code from the editor.
The Rust: cargo build task isn't working, because the directory you have open isn't a "Rust project" (Cargo package), it's a directory containing another directory, which is a Rust project.
Looking at your screenshot shows this, look at how the top line says rust_code/test_proj:
When you execute the task, Cargo is complaining that rust_code/Cargo.toml doesn't exist, which is true since it's located in rust_code/test_proj/Cargo.toml
If you look at the output of this screenshot, you can see that is the case:
Here you're executing cargo run manually. But the important difference is that you're inside the rust_code/test_proj directory.
Lastly simply executing rustc main.rs is failing since you aren't passing the arguments needed. So rustc doesn't know anything about your dependencies.
Try executing cargo build -v then you can see all the arguments that Cargo is passing to rustc.
Autocomplete does not work (only works on std, not on extra crates you add).
Try and open a directory that contains a Cargo.toml, then code completion should work for dependencies. If I don't, then I get the following notification, and code completion only works for the standard library as you said. That being said, RLS is weird sometimes.
If I had to guess, then I think RLS compiles the code, and at some stage extracts the needed information. Thus if the code doesn't compile, then code completion could be affected. But this is 100% an educated guess.
Alternatively, I have heard praise about using IntelliJ + the Rust plugin, but I haven't used it myself yet.
I have figured out one part: problems with running your code from within the VSCode. I had to modify default code-runner command for rust:
Original command:
"rust": "cd $dir && rustc $fileName && $dir$fileNameWithoutExt",
Changed to:
"rust": "if [ $(basename $dir) = 'examples' ]; then cargo run --example $fileNameWithoutExt; else cargo run; fi",
And now it works, and I can run my code quickly.
Part 2: Autocomplete still is very very bad, unfortunately. I am using RLS. there is this thing racer. Is it a better choice?
Alternatively, I have heard praise about using IntelliJ + the Rust
plugin, but I haven't used it myself yet.
As I mentioned in my previous post, IntelliJ, free edition does not have a debugger from what I can see. I need it.
I am wondering how people get a good autocomplete from Rust?
I have a problem with programming in Haxe. Whenever I try to run a code, I get an error:
Please don't add haxe/std to your classpath, instead set HAXE_STD_PATH env var.
I tried to find a solution - according to multiple sites, I'm supposed to change the environment variable HAXE_LIBRARY_PATH to HAXE_STD_PATH and set the value to actual path to the std file in my haxe folder. In my case, there was no such variable among my env vars, so I made HAXE_STD_PATH as a new one - and I still get the same error.
I'm using FlashDevelop and when I try to search for any class that would reference std, I can see in Type Explorer that there is a classpath that leads straight to haxe/std, which should not happen IMO. I looked at classpaths in Properties and the path to std was not listed, so I could not change it.
So problem could be in the classpath or in FlashDevelop settings.
Did anyone have the same problem?
Oh, and BTW I'm using Windows - and yes, restarting did not help.
I removed all: FD including program settings and HaxeToolkit (the whole map).
Then I reinstalled FD, Haxe (using the apps window from FD), Lime and openFL (from command window).
Now I don't get this error anymore.
So, I've been using Sublime for a while as a simple text editor, but I'm venturing into the land of plugins for work and I've run into an issue getting pylint to work. Specifically I have it installed and have the Sublime package manager working, but I'm not sure how to include paths in my sublime settings.
I haven't found very useful documentation on this point, but if you are willing to point me towards it that would be a perfectly acceptable answer. My basic issue is that currently every time I save a file, the following error message shows up:
"Please define the full path to 'lint.py' in the settings"
I understand this error message which is great, I just have no idea where the sublime settings are or what the standard format for defining a path is. Any help would be appreciated.
There are quite complete directions at the SublimeLinter GitHub page that should describe how to set everything up. Briefly, go to Preferences->Package Settings->SublimeLinter->Settings - Default to see where the different settings are defined. Then, open Preferences->Package Settings->SublimeLinter->Settings - User to change anything, as the main settings will be overwritten when the package is updated. Remember that settings files are in JSON format, so you'll need opening and closing curly brackets to enclose settings, and a comma between them:
{
"sublimelinter_delay": 30,
"sublimelinter_mark_style": "none"
}
I haven't gotten the error you have, are you sure you're using the regular SublimeLinter and not the new beta version? I just installed it fresh on my work machine (I've been using it for a while at home) and after restarting ST2 it's working like a charm with Python.
I had the same problem. I found it to be coming from the package "Pylinter". I removed Pylinter and added SublimeLinter, it covers more than python and is well used. I'm enjoying it quite a bit.
From your command line just run:
sudo easy_install pylint
sudo easy_install pep8
After that restart your sublime.
I encounter the same situation today. In my case, that is because I have not installed the 'pylint' in my system yet. It works fine after I installed the 'pylint' through pip.
Just for other people reference.
so once again, I'm having a little problem I can't figure out myself. Meaning, I'm pretty sure I know what the problem is, I just can't fix it.
I'm developing in C++ using Netbeans 7.01 with CMake 2.8.6. However, when I'm trying to build a project, I get the following error from CMake:
CMake Error: The path to the source directory:
H:/Projects/Netbeans/CppApplication_1/CONF=Release
contains unsupported character '='.
Please use a different source directory name.
Please note, that "CONF=Release" isn't a folder. It seems to be a configuration flag set by Netbeans, as it changes when I'm trying a debug build. So, my guess here is, that theres a space missing, or something similar. Unfortunately, I can't figure out where to change that. There are no options in any related Netbeans window, I can't find anything related in the configuration files for netbeans itself or the project either.
Did anyone here have experienced the same problem and found a solution to it? I would be very glad to hear it. If there's any information missing, let me know, I will add them as fast as possible.
Edit:
Just noticed there is already version 7.1 of netbeans, nice to know. However, even with this version, the same problem occurs.
You must specify the command you ran to allow for the error to be identified. However, it looks like you missed the "source-path" parameter.
The cmake command ends with the path to source and should be something like:
cmake -D CONF=Release <path to source>