dan-t / rusty-tags Goto Github PK

View Code? Open in Web Editor NEW

401.0 401.0 32.0 390 KB

Create ctags/etags for a cargo project

License: Other

Rust 100.00%

rusty-tags's People

Contributors

Stargazers

Watchers

rusty-tags's Issues

Async functions support

Unless I'm not using it right, rusty-tags for me does not create tags for async functions, which make up most of the functions I write :) So I thought why not at least create an issue on this.

Invoking via rusty-tags -s ./proj emacs

I was playing around with it, and I would like to have a flag --force-rebuild that forced a rebuild of all the files, and doesn't trust the cache. The use case for this was that I was recompiling rusty-tags and wanted to see if the new changes changed anything. (Changing how consts are matched).

Right now I'm just doing rm -rf ~/.rusty-tags and then rming any I know about, but I'm sure I'm missing some.

Alternatively, you could check the timestamp on rusty-tags, and if the files are older than the executable, rebuild them. That would also solve my problem.

Fails when rust src doesn't exist

After setting the RUST_SRC_PATH var pointing to a nonexistent location, rusty-tags fails. It should probably just generate tags as far as it can.

ctags in rust instructions don't work in interactive bash due to ls colors

In README, it tells me to create a script, but I wanted to execute interactively and was getting errors, due to color output in ls

Please consider using one of the following:

src_dirs=`ls --color=never -d $PWD/src/{liballoc,libarena,libbacktrace,libcollections,libcore,libflate,libfmt_macros,libgetopts,libgraphviz,liblog,librand,librbml,libserialize,libstd,libsyntax,libterm}`

src_dirs=`echo $PWD/src/{liballoc,libarena,libbacktrace,libcollections,libcore,libflate,libfmt_macros,libgetopts,libgraphviz,liblog,librand,librbml,libserialize,libstd,libsyntax,libterm}`

Rename default output file name to "tags"?

rusty-tags currently uses rusty-tags.vi name when generating tags for vim, but
that file name is not what vim looks for then looking for tags. It looks for a
file with name "tags" (and maybe a few other files?), so generating a "tags"
file would be better as currently we have to rename the generated file always.

An alternative would be to add a command line parameter for output file name,
but simply generating a "tags" file would be much more convenient.

Support workspace projects

I'm working on a workspace project, where the root Cargo.toml only contains the workspace section.

I would love if tags would be generated in one file rather than one rusty-tags.vi file for each crate in the workspace.

Broken feature omit dependencies

That was broken here: 0d7a33d#diff-b296903f197dacaca021f7e757a588e6L58

P.S. Of course, thanks for good project :D

Specify output filename

Would be great to be able to specify the output file. I'd have to manually rename it every time after running rusty-tags.

Support a scope operator

I've been hacking away at getting rusty-tags to work with tagbar, but the lack of a scope operator in the final output makes things difficult. Would it be possible to support a scoping of some sort in the tags? (At least a file-level scope?)

In the meantime, I can clean up the code I wrote to integrate with tagbar and add it to the wiki or something.

Permission Denied error when building tags on Windows

Hello,

I'm trying to build tags on Windows 10, but it fails with this output:

Using configuration: vi_tags='rusty-tags.vi', emacs_tags='rusty-tags.emacs', ctags_exe='None', ctags_options=''
Found ctags executable: UniversalCtags("ctags")
Fetching source and metadata ...
Creating tags for the standard library ...

Creating tags ...
   for source:
      C:\Users\s\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src\liballoc
      C:\Users\s\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src\libbacktrace
      C:\Users\s\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src\libcore
      C:\Users\s\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src\libstd
      C:\Users\s\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src\libterm

   cached at:
      C:\Users\s\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src\.tmp2UQ9VR
ctags: cannot open tag file : Permission denied

This happens both when run as an administrator and otherwise. According to other people's output, the cached into a file named rusty-tags.emacs (since I'm building Emacs tags, though the issue happens for Vi tags as well). I tried creating one, but the error persists. No file starting with .tmp is found in the directory either.

Building tags from CTags itself works fine, though I would love to have the convenience of rusty-tags to handle the standard library etc.

Type Aliases

https://doc.rust-lang.org/reference.html#type-aliases

We can match these too.

Tries to open cached files even if they do not exist

When I run rusty-tags on my project, I get this message:

$ rusty-tags vi
Fetching source of dependencies ...
No such file or directory (os error 2)

If I use opensnoop to look at what rusty-tags is failing to open, it's a cached tag file in my home directory:

2124038712  81853 rusty-tags    -1 /Users/me/.rusty-tags/cache/clippy_lints-0.0.71.vi

If I create that file, I get the same no such file error, but now it's trying to load a new cache file:

2124038712  81958 rusty-tags    -1 /Users/me/.rusty-tags/cache/clippy-0.0.71.vi

It seems like these cache files should be built if they don't exist, not just failing the program. I'm using rusty-tags version 0.8.2, rustc nightly and OS X 10.10.5

Does not find dependencies in Fedora (32) for emacs

Generating the code for emacs only finds the code in the current directory. VI version seesm to find depdencies OK in the cargo cache.

cargo install rusty-tags
rusty-tags emacs
$ wc -l rusty-tags.emacs
30 rusty-tags.emacs
$ wc -l rusty-tags.vi
1023 rusty-tags.vi

Cannot browse into dependencies with emacs

vi generated tags work correctly

Mention what kind of tag this is about

The first sentence of the README currently is

A command line tool that creates tags for a cargo project and all of its dependencies.

What is a “tag” in this context? It first, I thought it was about creating a git tag when cargo publish run. Then the mention of ctags later in the text hinted it was probably not.

SublimeText Support ?

This is a question, not an issue, and hopefully the easiest way to get in touch, publicly.

I am using Sublime Text, which supports tag files created via ctags -R -f .tags using the CTags Plugin.

Is rusty-tags able to generate those as well ?

Thank you

Fails on linux

When I try to generate tags for a rust project on linux I get the following error message. (FWIW it worked on a windows machine)

rusty-tags emacs
Fetching source and metadata ...
Creating tags for: ["bud"] ...
thread '' panicked at 'called Result::unwrap() on an Err value: Message("ctags: invalid option -- 'e'\n\tTry 'ctags --help' for a complete list of options.\n")', src/libcore/result.rs:997:5
note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.
thread 'main' panicked at 'Thread pool worker panicked', /home/beni/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.9/src/lib.rs:236:13

go to definition not behaving correctly

Here is the code in question: https://github.com/kindlychung/stridist/blob/kindlychung-patch-1/src/main.rs#L43

If you put the cursor at next and then c-], it will lead you to one of the testing functions, which is incorrect.

Supprort XDG-DIRS for storing information

Could you please add support for the $XDG_DATA_HOME and $XDG_CONFIG_HOME environment variables instead of hard-coding "~/.rusty-tags" as the directory for storing data in?

Cannot find ctags executable in arch linux

I have got ctags installed, but for some reason it's printing the following error when I try to generate tags by running rusty-tags vi. Any idea why this might happen?

Couldn't find 'ctags' executable! Searched for executables with names: [""]. Is 'ctags' correctly installed?

Absolute filepaths may cause issue

I tried using rusty-tags with Atom's symbol-view, which should be fine accepting ctag files. And while the dialog works in terms of searching for a symbol, the target file cannot be opened. I suspect this may be due to the absolute filepath in the tags file, which may not be non-standard.

Issue which lead me to this: atom/symbols-view#108

I'd suggest adding a flag for producing relative filepaths, so rusty-tags can be used with lesser-capable editors.

Specify output directory

I'm using NixOS, so the natural way to get and update my rust source directory involves installing it to a read-only filesystem. It'd be keen, therefore, to be able to tell rusty-tags to write its tag file, as opposed to into the root of the rustlib source.

I could probably produce a PR for this, if that'd help.

Specify how to run this in background

Hello.
It would be nice to specify how to run rusty-tags in the background, even though it is not specific to this plugin.

For instance, in neovim, the script would be the following:

setlocal tags=./rusty-tags.vi;/,$RUST_SRC_PATH/rusty-tags.vi

function! s:rustyTags()
    let cmd = "rusty-tags vi --start-dir=" . expand('%:p:h') . "&"
    call jobstart(cmd)
endfunction

autocmd BufWrite *.rs :silent call s:rustyTags()

I don't know how it must be written for vim, but I believe it will be similar.

Thanks.

[feature request] Flag for skipping impls

Currently if I have a struct Foo { ... } and impl Foo { ... }, rusty-tags generates two tags for Foo, one for the type definition, another one for the impl. Most of the time unless I'm looking for a function I only want type definitions, so a flag for omitting impls would be helpful.

Rusty-tags should optionally accept a file as a starting point to search for Cargo.toml

I do most of my editing from a directory that contains multiple rust projects. This means that when vim runs rusty-tags vi it starts in a directory that isn't even a rust project!

the rusty-tags binary should accept an optional file path as a starting point for the Cargo.toml search (and subsequent tag generation).

Do you have suggestions for vim -t support?

Thanks for making this awesome project. Do you have any suggestions for being able to open (n)vim and jump to a tag via the -t tag_name command line switch? Currently that throws an error about the tags file not being found.

Thanks!

Currently does not build

This is on x86_64 linux, latest rust (rustc 1.32.0-nightly (d09466ceb 2018-11-30)):

cargo install rusty-tags                        ~/src/giti
    Updating crates.io index
  Installing rusty-tags v3.5.1
   Compiling libc v0.2.62
   Compiling getrandom v0.1.12
   Compiling cfg-if v0.1.10
   Compiling proc-macro2 v1.0.5
   Compiling lazy_static v1.4.0
   Compiling ppv-lite86 v0.2.5
   Compiling unicode-xid v0.2.0
   Compiling serde v1.0.101
   Compiling ryu v1.0.0
   Compiling bitflags v1.2.0
   Compiling syn v1.0.5
   Compiling unicode-width v0.1.6
   Compiling itoa v0.4.4
   Compiling ansi_term v0.11.0
   Compiling remove_dir_all v0.5.2
   Compiling strsim v0.8.0
   Compiling semver-parser v0.7.0
   Compiling vec_map v0.8.1
   Compiling scoped_threadpool v0.1.9
   Compiling fnv v1.0.6
   Compiling textwrap v0.11.0
   Compiling c2-chacha v0.2.2
   Compiling semver v0.9.0
   Compiling atty v0.2.13
   Compiling num_cpus v1.10.1
   Compiling dirs v1.0.5
error[E0658]: imports can only refer to extern crate names passed with `--extern` on stable channel (see issue #53130)
  --> /home/sirver/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.1.12/src/error_impls.rs:13:5
   |
8  | extern crate std;
   | ----------------- not an extern crate passed with `--extern`
...
13 | use std::io;
   |     ^^^
   |
   = help: add #![feature(uniform_paths)] to the crate attributes to enable
note: this import refers to the extern crate imported here
  --> /home/sirver/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.1.12/src/error_impls.rs:8:1
   |
8  | extern crate std;
   | ^^^^^^^^^^^^^^^^^

   Compiling clap v2.33.0
error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: Could not compile `getrandom`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `rusty-tags v3.5.1`, intermediate artifacts can be found at `/tmp/cargo-installPOYwdM`

Caused by:
  build failed

`Expected one matching path for '/home/dpc/.cargo/registry/src/github.com-*'!`

Hi,

No matter which project I try, I get:

% rusty-tags vi
Fetching source of dependencies ...
Expected one matching path for '/home/dpc/.cargo/registry/src/github.com-*'!

I don't seem to have ~/.cargo/registry/

Paths are absolute

I notice that rusty-tags calls ctags with an absolute path, and falls back to a path that's absolute in the case where the manifest returns a src_path that's relative. The problem is that I prefer to use docker to contain the environment for different languages/projects and install vim locally. Doing this breaks rusty-tags however because of path mismatches between local and container environments. I'd like to create a PR that allows for a absolute path option if a env var to the cargo registries location is present.

stdlib instructions are not compatible with the MacOS version of ctags

MacOS users cannot tag the standard library unless they get another Ctags version,
e.g. how described here: http://gmarik.info/blog/2010/10/08/ctags-on-OSX

If you want this to be added to the readme I can write a sentence and a PR; if not, I just leave this here for future reference ;)

ctrl-] looks for a tags file

'rusty-tags vi' creates a 'rusty-tags.vi', however when I use 'ctrl-]', vi looks for a tags file. When I create a tags file 'ctags -R .', the function definition is not found.

The project has been built with Cargo.

Record enum variants.

It would be nice if we could jump to enum variants. I'm not sure how you'd match the line with a regex however.

rusty-tags fails silently

i'm not sure why it's failing or exactly how to reproduce the bug. i'm using the default config, trying to generate tags for remacs source.

$ cd code/remacs
$ rusty-tags -v -s ./rust_src emacs    # also fails with vi
Using configuration: vi_tags='rusty-tags.vi', emacs_tags='rusty-tags.emacs', ctags_options=''
Found Excuberant Ctags with executable 'ctags'
Fetching source and metadata ...

i've been able to generate tags for other projects.

rusty-tags doesn't seem to work with cargo workspaces

rusty-tags tries to open Cargo.lock in the crate instead of the workspace

fail gracefully when tags can not be generated for subcomponent

I have a project with a dependency given as a github url. And no tags are generated at all.

Cargo.toml

name = "scrape"
version = "0.1.0"
authors = ["Nils Wireklint <[email protected]>"]

[dependencies]
select = "0.3.0"

[dependencies.url]
git = "https://github.com/servo/rust-url"

~/a/r/scrape *master $ rusty-tags vi -v


Missing source 'url-52234db0c36de07437dab29c659fa9de340f18fa', might be platform specific

Creating tags ...
   for source:
      /home/spill/arbete/rust/scrape

   cached at:
      /home/spill/arbete/rust/scrape/source-temp-dir.XJGo1rQ3At6M/src_tags

Missing source 'url-52234db0c36de07437dab29c659fa9de340f18fa', might be platform specific

Removing the url dependency from Cargo.toml makes it possible to generate tags for the rest of the project.

Instead of crashing and not generating any tags on this kind of dependency it would be better to generate all other possible tags and emit a warning: "could not generate tags for dependency.url - (source not available|currently not supported)" or something. I am not familiar with cargo enough to tell whether the source is accessible, I would assume so but don't know. I can give you a tree listing or the full repo if you want to dig around

edit: can be reproduced on a naked new cargo project. simply add one regular semver dependency and then a github dep

tags for rust standard library not generated

Hi,

After install rusty-tags from cargo install or from this Git repo with cargo build I use the rusty-tags setting RUST_SRC_PATH env variable.

From verbose mode I see

❯ rusty-tags --force-recreate --verbose  vi
Switching to single threaded for verbose output
Using configuration: vi_tags='rusty-tags.vi', emacs_tags='rusty-tags.emacs', ctags_exe='Some("/home/albertop/GitHub/ctags/ctags")', ctags_options=''
Found ctags executable: UniversalCtags("/home/albertop/GitHub/ctags/ctags")
Fetching source and metadata ...
Creating tags for the standard library ...

Creating tags ...
   with command: "/home/albertop/GitHub/ctags/ctags" "--recurse" "--languages=Rust" "-o" "/home/albertop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/.tmpflvfrb"

   for source:

   cached at:
      /home/albertop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/.tmpflvfrb

Move tags ...
   from:
      /home/albertop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/.tmpflvfrb
   to:
      /home/albertop/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rusty-tags.vi
Found package of (files, 0.1.0) with source at '/home/albertop/Dev/rust/files/src'
Found workspace members: [(files, 0.1.0)]
Building tree for (files, 0.1.0)
Creating tags for: files ...

Tags for cargo project are ok but not for standard library.

Workaround is to run ctags under $RUST_SRC_PATH manually.

rusty-tags blocks vim ~5 seconds when :w executes in a very large project

Hi,

I use rusty-tags for a while. It is a wonderful plugin. But recently I found that every time when I execute ":w", the vim will hang for few seconds. Is there anyway to execute the refresh tags file in async way?

No generated file in library with only lib.rs

In a library with only lib.rs (specifically this https://github.com/pdf-rs/pdf_derive), rusty-tags vi doesn't generate any file.

No Such File or Directory

I entered a directory with a rust project. I'm in the same level as the cargo.toml.

Run rusty-tags vi

I get this error

Fetching source of dependencies ...
No such file or directory (os error 2)

I'm on Ubuntu 16.04 and rusty-tags v0.9.1

It seems that it cannot make a tags which include std

My vim can not jump to an std file.

Empty (but present) dependencies table in `Cargo.toml` leads to error

Running rusty-tags on a crate with the following Cargo.toml:

[package]
name = "sparse"
version = "0.1.0"
authors = ["Michael Lamparski <[email protected]>"]

[dependencies]

Produces the error:

Couldn't get Array of Tables entry for 'package'!

Removing the [dependencies] section (or adding an item to it) eliminates the error.
This is the issue that #11 was attempting to address.

CPU hungry

I'm not sure how to provide better diagnostics than this, but for a moderately sized project (in terms of dependencies) rusty-tags consumes a lot of CPU - all 4 procs peg for about 2 minutes every time it's run. This isn't a huge deal, except when trying to use it as described in the README - to run on every save in Vim. Additionally, it seems to acquire a lock on the code files, so that cargo waits for it to complete.

Am I doing something wrong? Can I provide more information? My Cargo.toml looks like:

...
[dependencies]
error-chain = "^0.11"
tokio-tls = { version = "^0.1", features = ["tokio-proto"] }
tokio-core = "^0.1"
tokio-proto = "^0.1"
tokio-service = "^0.1"
futures = "^0.1"
hyper = "^0.11"
hyper-tls = "^0.1"
native-tls = "^0.1"
url = "^1.0"
uritemplate = "^0.1"
oauth2 = "^1.1"
rand = "^0.3"
base64 = "^0.7"
toml = "^0.4"
serde = "^1.0"
serde_derive = "^1.0"

rusty-tags fails when ~/.cargo doesn't exists

rusty-tags fails when .cargo directory does not exist:

# rm -rf ~/.cargo
# rusty-tags vi
No such file or directory (os error 2)
# rusty-tags vi
Fetching source of dependencies ...

Resolve build failure

term v0.1.13 fails with 25 errors using a recent nightly (rustc 1.0.0-nightly (809a554fc 2015-03-23) (built 2015-03-24)). Those errors are resolved when I change the term version to "*", but then these 3 errors pop up.

src/dependencies.rs:182:24: 182:34 error: the trait `std::ffi::AsOsStr` is not implemented for the type `P` [E0277]
src/dependencies.rs:182    let mut file = try!(File::open(path));
                                               ^~~~~~~~~~
<std macros>:1:1: 6:57 note: in expansion of try!
src/dependencies.rs:182:19: 182:42 note: expansion site
src/tags.rs:114:18: 114:37 error: the trait `std::ffi::AsOsStr` is not implemented for the type `P` [E0277]
src/tags.rs:114                 .open(into_tag_file)
                                 ^~~~~~~~~~~~~~~~~~~
src/tags.rs:317:8: 317:28 error: the trait `std::ffi::AsOsStr` is not implemented for the type `P` [E0277]
src/tags.rs:317    cmd.current_dir(git_dir)
                       ^~~~~~~~~~~~~~~~~~~~
error: aborting due to 3 previous errors
Could not compile `rusty-tags`.

I haven't delved any deeper, but I suspect recent changes to Rust may explain it.

What version are you using? The README links to a page where rust nightlies and alpha.2 are available, so it's not totally clear.

Support for CARGO_HOME env variable?

I have CARGO_HOME variable to set it in non-default location so when i run rusty-tags:

Expected one matching path for 'C:\Users\Douman\.cargo\registry\src\github.com-*'!

Seems like rusty-tags is not able to pick up it from right directory?

p.s. why it is decided to not create tags in case of failing to find dependency?

Don't throw error message if dependencies section is empty

A default Cargo.toml will include a [dependencies] section which has nothing in it. Running rusty-tags vi will throw the error: Couldn't get Array of Table entries for 'package'!. Removing this section makes the command run without errors, so it looks like it is a problem with having 0 dependencies.

Support for rust core

crash when trying to make ctags for fst

I think this is due to rusty-tags getting into a state where it thinks that fst has a cyclic dependency on itself. The error seems to be coming from src/tags.rs:237.

Steps to Reproduce

> git clone https://github.com/dan-t/rusty-tags.git
> cd rusty-tags && cargo build
> git clone https://github.com/BurntSushi/fst.git
> cd fst && ../rusty-tags/target/debug/rusty-tags vi

Output from some potentially interesting commands

Output of `RUST_BACKTRACE=1 ../rusty-tags/target/debug/rusty-tags vi`

Fetching source and metadata ...
Creating tags for: ["fst"] ...
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Message("No such file or directory (os error 2)")', libcore/result.rs:1009:5
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Message("No such file or directory (os error 2)")', libcore/result.rs:1009:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   6: rust_begin_unwind
             at libstd/panicking.rs:326
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
             at libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at libcore/result.rs:808
  10: rusty_tags::tags::update_tags::{{closure}}::{{closure}}
             at src/tags.rs:69
  11: <F as scoped_threadpool::FnBox>::call_box
             at /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:71
  12: scoped_threadpool::Pool::new::{{closure}}
             at /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:127
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   6: rust_begin_unwind
             at libstd/panicking.rs:326
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
             at libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at libcore/result.rs:808
  10: rusty_tags::tags::update_tags::{{closure}}::{{closure}}
             at src/tags.rs:69
  11: <F as scoped_threadpool::FnBox>::call_box
             at /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:71
  12: scoped_threadpool::Pool::new::{{closure}}
             at /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:127
thread 'main' panicked at 'Thread pool worker panicked', /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:236:13
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::begin_panic
             at libstd/panicking.rs:411
   6: scoped_threadpool::Scope::join_all
             at /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:236
   7: <scoped_threadpool::Scope<'pool, 'scope> as core::ops::drop::Drop>::drop
             at /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:248
   8: core::ptr::drop_in_place
             at libcore/ptr.rs:59
   9: scoped_threadpool::Pool::scoped
             at /home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:182
  10: rusty_tags::tags::update_tags
             at src/tags.rs:65
  11: rusty_tags::update_all_tags
             at src/main.rs:94
  12: rusty_tags::execute
             at src/main.rs:55
  13: rusty_tags::main
             at src/main.rs:47
  14: std::rt::lang_start::{{closure}}
             at libstd/rt.rs:74
  15: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  16: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:103
  17: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  18: std::rt::lang_start
             at libstd/rt.rs:74
  19: main
  20: __libc_start_main
  21: _start

Output of `../rusty-tags/target/debug/rusty-tags -v vi`

Switching to single threaded for verbose output
Using configuration: vi_tags='rusty-tags.vi', emacs_tags='rusty-tags.emacs', ctags_exe='None', ctags_options=''
Found ctags executable: ExuberantCtags("ctags")
Fetching source and metadata ...
Found package of (regex-syntax, 0.3.9) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.3.9/src'
Found package of (quickcheck, 0.7.2) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/quickcheck-0.7.2/src'
Found package of (lazy_static, 0.2.11) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-0.2.11/src'
Found package of (rand_core, 0.3.0) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/rand_core-0.3.0/src'
Found package of (fuchsia-zircon, 0.3.3) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/fuchsia-zircon-0.3.3/src'
Found package of (fst, 0.3.2) with source at '/home/ethan/repos/fst/src'
Found package of (cloudabi, 0.0.3) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/cloudabi-0.0.3'
Found package of (bitflags, 1.0.4) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/bitflags-1.0.4/src'
Found package of (rand, 0.5.5) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.5.5/src'
Found package of (libc, 0.2.43) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.43/src'
Found package of (winapi-i686-pc-windows-gnu, 0.4.0) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-i686-pc-windows-gnu-0.4.0/src'
Found package of (rand_core, 0.2.2) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/rand_core-0.2.2/src'
Found package of (winapi-x86_64-pc-windows-gnu, 0.4.0) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-x86_64-pc-windows-gnu-0.4.0/src'
Found package of (fnv, 1.0.6) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/fnv-1.0.6'
Found package of (fst-levenshtein, 0.2.1) with source at '/home/ethan/repos/fst/fst-levenshtein/src'
Found package of (utf8-ranges, 1.0.2) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/utf8-ranges-1.0.2/src'
Found package of (fst-regex, 0.2.1) with source at '/home/ethan/repos/fst/fst-regex/src'
Found package of (byteorder, 1.2.7) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/byteorder-1.2.7/src'
Found package of (winapi, 0.3.6) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-0.3.6/src'
Found package of (memmap, 0.6.2) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/memmap-0.6.2/src'
Found package of (fuchsia-zircon-sys, 0.3.3) with source at '/home/ethan/.cargo/registry/src/github.com-1ecc6299db9ec823/fuchsia-zircon-sys-0.3.3/src'
Found workspace members: [(fst, 0.3.2)]
Building tree for (utf8-ranges, 1.0.2)
Building tree for (libc, 0.2.43)
Building tree for (fnv, 1.0.6)
Building tree for (byteorder, 1.2.7)
Building tree for (rand_core, 0.3.0)
Found dependencies of (rand_core, 0.2.2): [(rand_core, 0.3.0)]
Building tree for (rand_core, 0.2.2)
Building tree for (regex-syntax, 0.3.9)
Found dependencies of (memmap, 0.6.2): [(winapi, 0.3.6), (libc, 0.2.43)]
Building tree for (memmap, 0.6.2)
Building tree for (winapi-i686-pc-windows-gnu, 0.4.0)
Found dependencies of (winapi, 0.3.6): [(winapi-x86_64-pc-windows-gnu, 0.4.0), (winapi-i686-pc-windows-gnu, 0.4.0)]
Building tree for (winapi, 0.3.6)
Building tree for (fuchsia-zircon-sys, 0.3.3)
Found dependencies of (fst-regex, 0.2.1): [(utf8-ranges, 1.0.2), (fst, 0.3.2), (regex-syntax, 0.3.9)]
Building tree for (fst-regex, 0.2.1)
Building tree for (lazy_static, 0.2.11)
Found dependencies of (fuchsia-zircon, 0.3.3): [(fuchsia-zircon-sys, 0.3.3), (bitflags, 1.0.4)]
Building tree for (fuchsia-zircon, 0.3.3)
Found dependencies of (quickcheck, 0.7.2): [(rand_core, 0.2.2), (rand, 0.5.5)]
Building tree for (quickcheck, 0.7.2)
Found dependencies of (fst-levenshtein, 0.2.1): [(utf8-ranges, 1.0.2), (fst, 0.3.2)]
Building tree for (fst-levenshtein, 0.2.1)
Building tree for (winapi-x86_64-pc-windows-gnu, 0.4.0)
Found dependencies of (fst, 0.3.2): [(fst-regex, 0.2.1), (memmap, 0.6.2), (fnv, 1.0.6), (byteorder, 1.2.7), (quickcheck, 0.7.2), (rand, 0.5.5), (lazy_static, 0.2.11), (fst-levenshtein, 0.2.1)]
Building tree for (fst, 0.3.2)
Building tree for (bitflags, 1.0.4)
Found dependencies of (cloudabi, 0.0.3): [(bitflags, 1.0.4)]
Building tree for (cloudabi, 0.0.3)
Found dependencies of (rand, 0.5.5): [(libc, 0.2.43), (fuchsia-zircon, 0.3.3), (winapi, 0.3.6), (rand_core, 0.2.2), (cloudabi, 0.0.3)]
Building tree for (rand, 0.5.5)
Creating tags for: ["fst"] ...

Sources of depth=1
   Recreating tags for (fst-levenshtein, 0.2.1), because of missing tags file at '"/home/ethan/repos/fst/fst-levenshtein/rusty-tags.vi"'
   Recreating tags for (fst-regex, 0.2.1), because of missing tags file at '"/home/ethan/repos/fst/fst-regex/rusty-tags.vi"'

Creating tags ...
   with command: "ctags" "--recurse" "--languages=Rust" "--langdef=Rust" "--langmap=Rust:.rs" "--regex-Rust=/^[ \\t]*(#\\[[^\\]]\\][ \\t]*)*(pub[ \\t]+)?(extern[ \\t]+)?(\"[^\"]+\"[ \\t]+)?(unsafe[ \\t]+)?fn[ \\t]+([a-zA-Z0-9_]+)/\\6/f,functions,function definitions/" "--regex-Rust=/^[ \\t]*(pub[ \\t]+)?type[ \\t]+([a-zA-Z0-9_]+)/\\2/T,types,type definitions/" "--regex-Rust=/^[ \\t]*(pub[ \\t]+)?enum[ \\t]+([a-zA-Z0-9_]+)/\\2/g,enum,enumeration names/" "--regex-Rust=/^[ \\t]*(pub[ \\t]+)?struct[ \\t]+([a-zA-Z0-9_]+)/\\2/s,structure names/" "--regex-Rust=/^[ \\t]*(pub[ \\t]+)?mod[ \\t]+([a-zA-Z0-9_]+)\\s*\\{/\\2/m,modules,module names/" "--regex-Rust=/^[ \\t]*(pub[ \\t]+)?(static|const)[ \\t]+([a-zA-Z0-9_]+)/\\3/c,consts,static constants/" "--regex-Rust=/^[ \\t]*(pub[ \\t]+)?trait[ \\t]+([a-zA-Z0-9_]+)/\\2/t,traits,traits/" "--regex-Rust=/^[ \\t]*macro_rules![ \\t]+([a-zA-Z0-9_]+)/\\1/d,macros,macro definitions/" "-o" "/tmp/.tmp8gjdLR" "/home/ethan/repos/fst/fst-levenshtein/src"

   for source:
      /home/ethan/repos/fst/fst-levenshtein/src

   cached at:
      /tmp/.tmp8gjdLR

Copy tags ...
   from:
      /tmp/.tmp8gjdLR
   to:
      /home/ethan/.rusty-tags/cache/.tmprHo5gv

Move tags ...
   from:
      /home/ethan/.rusty-tags/cache/.tmprHo5gv
   to:
      /home/ethan/.rusty-tags/cache/fst-levenshtein-7207295818956455412.vi

Merging ...
   tags:
      /tmp/.tmp8gjdLR
      /home/ethan/.rusty-tags/cache/utf8-ranges-18205610573370416105.vi
      /home/ethan/.rusty-tags/cache/fst-5085178582101757549.vi

   into:
      /home/ethan/repos/fst/fst-levenshtein/src/.tmpb9RqVL
No such file or directory (os error 2)

Cannot create rusty-tags.vim

When I run rusty-tags vi in a project I get this output:

# rusty-tags vi
Fetching source of dependencies ...
No such file or directory (os error 2)

However, rusty-tags emacs works

Reproducing:

# cargo install rusty-tags
# cargo new test_project --bin
# rusty-tags vi

Path Dependancies

I have separated my project into a few different crates the live side by side, with a path dependancy
Ex:

[dependencies]
gba = {path = "../gba"}

And it doesn't seem like it's picked up the tags. How would I invoke it to get rusty-tags to nap those dependancies too?

I have them all in the same git repository, since I want to keep them in sync, and do not want to use git submodules, otherwise I'd use a file:// git dep.

Too many open files on large project

I'd like to use rusty-tags to jump into dependencies. My current setup using ctags just works for files in the local repo. But unfortunately I keep getting the error:

Too many open files (os error 24) at path "/var/folders/8l/77fwhqdx3tvfnn3s_k7nlwgm0000gn/T/.tmpxEFnsF"

Is there any way to limit the number of files open at a given time?
I've tried with ctags as well as universal-ctags but it doesn't seem to make a difference.

Mac OS 10.15.5

dan-t / rusty-tags Goto Github PK

rusty-tags's People

Contributors

Stargazers

Watchers

Forkers

rusty-tags's Issues

Steps to Reproduce

Output from some potentially interesting commands

Output of RUST_BACKTRACE=1 ../rusty-tags/target/debug/rusty-tags vi

Output of ../rusty-tags/target/debug/rusty-tags -v vi

Recommend Projects

Recommend Topics

Recommend Org

Output of `RUST_BACKTRACE=1 ../rusty-tags/target/debug/rusty-tags vi`

Output of `../rusty-tags/target/debug/rusty-tags -v vi`