anaconda_racer: completion error

[c0gent]

Racer works fine from the command line. Auto-completion searches in Sublime have some strange behavior. For example, typing use std::io::B, then pausing/waiting...

• Immediately pops up the 'basic/naive' autocomplete suggestion box
• After waiting 5 or 10 seconds, moving the cursor up or down with the keyboard replaces the basic suggestion box with a correct, working anaconda suggestion box with entries matching those returned by running racer on the command line. Moving the cursor to another line or position, then back to the end (without typing anything new) will pop up the working anaconda box
• Produces the following stack trace message in the console:

anaconda_racer: completion error
error: internal compiler error: Error constructed but not emitted
thread 'searcher' panicked at 'explicit panic', /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/syntex_syntax-0.32.0/src/errors/mod.rs:361
stack backtrace:
   1:     0x563246a92c69 - std::sys::backtrace::tracing::imp::write::h482d45d91246faa2
   2:     0x563246a96d2c - std::panicking::default_hook::_{{closure}}::h89158f66286b674e
   3:     0x563246a95f4e - std::panicking::default_hook::h9e30d428ee3b0c43
   4:     0x563246a96668 - std::panicking::rust_panic_with_hook::h2224f33fb7bf2f4c
   5:     0x563246944d04 - std::panicking::begin_panic::h6da27a7ee15843ce
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:384
   6:     0x56324695dfc9 - _<syntex_syntax..errors..DiagnosticBuilder<'a> as core..ops..Drop>::drop::h09b55b7964875310
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/syntex_syntax-0.32.0/src/errors/mod.rs:3
   7:     0x5632468eecb0 - racer::ast::string_to_crate::h4f17cebc6d7141d3
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/ast.rs:51
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/ast.rs:34
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/ast.rs:49
   8:     0x5632468fca9c - racer::ast::parse_use::h8d66a3ebde7e2fcd
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/ast.rs:808
   9:     0x56324692dc03 - racer::matchers::match_use::hfc60d379341e44c5
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/matchers.rs:512
  10:     0x563246926ae9 - racer::matchers::match_types::h28895858e333b834
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/matchers.rs:27
  11:     0x563246912d26 - racer::nameres::run_matchers_on_blob::h1aec6042601d1aad
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/nameres.rs:716
  12:     0x56324691207b - racer::nameres::search_scope::h2093edca1aab4932
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/nameres.rs:665
  13:     0x56324691bae5 - racer::nameres::search_local_scopes::h6b9d5789e6420cb9
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/nameres.rs:753
  14:     0x56324691e7f2 - racer::nameres::resolve_name::hb81ab693da9463ea
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/nameres.rs:897
  15:     0x563246920b80 - racer::nameres::resolve_path::hab523e48773820ff
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/nameres.rs:976
  16:     0x5632468e8f23 - racer::core::complete_from_file::h05f097721f7bd7a6
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/racer/core.rs:661
  17:     0x563246825e25 - std::panicking::try::do_call::hbcbb667f329b4b0f
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/bin/main.rs:160
                        at /home/nick/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-1.2.10/src/bin/main.rs:109
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panic.rs:256
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:327
  18:     0x563246a9e816 - __rust_maybe_catch_panic
  19:     0x56324684b870 - _<F as alloc..boxed..FnBox<A>>::call_box::hc613c39d91cc369a
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:303
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panic.rs:312
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/liballoc/boxed.rs:587
  20:     0x563246a94d22 - std::sys::thread::Thread::new::thread_start::he0bf102845911132
  21:     0x7fb91bc6b6a9 - start_thread
  22:     0x7fb91b78aeec - clone
  23:                0x0 - <unknown>
ERROR:racer: Search thread paniced: Any

I'm using the latest versions of anaconda and anaconda_rust, with all configuration/paths correct:

{
    "anaconda_rust_linting": false,
    "rust_format_on_save": false,
    "rustc_binary_path": "/home/nick/.cargo/bin/rustc",
    "racer_binary_path": "/home/nick/.cargo/bin/racer",
    "rustfmt_binary_path": "/home/nick/.cargo/bin/rustfmt",
    "rust_src_path": "/usr/local/src/rust/src"
}

It seems like this is an issue with syntex_syntax or possibly racer but as I mentioned, racer works perfectly from the command line.

Please let me know what other information might be useful.

[DamnWidget]

Your report is pretty complete already, this problem is probably due some environmental issue, I am working (sadly slowly) in a new redesigned version of the plugin that calls racer directly using a C FFI between Python and Rust using this custom crate to fix issues like this one and others that I already detected.

The delay that you noticed in the completion is due the fact that anaconda is an asynchronous client-server architecture based plugin (so it doesn't make ST3 to lock while processing heavy requests) so when a requests produce a result we inject it into the "naive" ST3 native completions.

[c0gent]

Interesting. I'm using cffi to do the exact same thing, allowing Python to call into Rust, for one of my projects, tyro. Let me know if I can be of any help :)

[DamnWidget]

What a coincidence :) I will push what I have into a new branch and let you know so you can take a look, I think everything is done it was easy stuff but I am still working in the part that compile the binary parts automatically when first installation and/or updates.

[DamnWidget]

Hi, you can take a look at the new branch, you can even clone it and test it in your ST3 (probably broken on the automatic compilation but you can just compile it manually).

https://github.com/DamnWidget/anaconda_rust/tree/WIP

[c0gent]

I'll have a look as soon as I get a chance.

[c0gent]

I'm afraid I'm just not acclimated enough with Sublime plugins to give you any useful feedback about this project at the moment. Is there any way you could get me oriented a bit and give me some idea, for example, the roles of the various project directories?

As someone almost completely unfamiliar with Sublime plugin development I'll be more of a hindrance than a help for the time being but if you have the patience I wouldn't mind being pointed in the right direction.

[DamnWidget]

You can have a look at the developer handbook if you like but basically, anaconda is split between two different components, the GUI related code that is executed by the ST3 embedded Python interpreter and the JsonServer that is actually the one that do all the linting, completion, definition finding work in an asynchronous fashion and send results back to the GUI related code using a custom JSON protocol when there are results available.

Note: The server code is really implemented in anaconda, anaconda-rust is a plugin for anaconda so it doesn't implements any server related code it just implements a common interface (to all the anaconda's plugins) to expose the rust tools to lint, complete etc

About the directories hierarchy:

• anaconda_lib: this module contains code that is being used by the GUI and the JsonServer components
• commands: ST3 GUI specific commands, those are called from the ST3 events system
• listeners: ST3 GUI events listeners
• messaged: this is just for Package Control
• plugin: this one contains all the anaconda_rust code that is "called" (really the JsonServer calls it) from the commands and listeners
• rust-anaconda: this is the custom crate that we need to compile on install/updates and creates the shared C library that we can use to expose Rust methods directly into Python using cFFI or Ctypes

The plugin directory contains the handler directory that is imported and lazy evaluated by the anaconda's jsonserver when a client first requests any method from the rust plugin ( so we don't really load the anaconda's plugins into ST3 memory until we really need them ).

Inside the handlers directory there is a python handler for any given command, the commands directory implements those commands (but they could be implemented directly in the handlers files for example), the linting directory just implements the linting features and the rust_anaconda is the cFFI/Ctypes wrapper around the C shared library.

That is more or less everything

[c0gent]

Really helpful. Thank you.

You should add this info to the README or to a CONTRIBUTING.md file or some such.