Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syntastic compatibility nonfunctional when using nightly #97

Closed
ExpHP opened this issue Aug 12, 2016 · 6 comments
Closed

Syntastic compatibility nonfunctional when using nightly #97

ExpHP opened this issue Aug 12, 2016 · 6 comments

Comments

@ExpHP
Copy link

ExpHP commented Aug 12, 2016

There are several factors possibly at play here (rustc, rustup, rust.vim, syntastic); I chose to report on rust.vim as it is the middleman.

Steps to reproduce

  1. Install both rust.vim and syntastic. For full disclosure: from a clean vim, I installed pathogen, cloned the plugin repos into .vim/patho, and used this .vimrc

    execute pathogen#infect('patho/{}')
    set statusline+=%#warningmsg#
    set statusline+=%{SyntasticStatuslineFlag()}
    set statusline+=%*
    
  2. Make two new crates, one on nightly

    cargo new --bin test-nightly && (cd test-nightly && rustup override set nightly)
    cargo new --bin test-stable
    

3. For each one, do the following:

    $ cd <test dir name>
    $ vim src/main.rs

Verify that all lights are green:

    :SyntasticInfo
    Syntastic version: 3.7.0-180 (Vim 704, Linux)
    Info for filetype: rust
    Global mode: active
    Filetype rust is active
    The current file will be checked automatically
    Available checker: rustc
    Currently enabled checker: rustc

Insert a deliberate error (unpared parenthesis) and write the file.

    O(<Esc>:w<Enter>

What occurs

In test-stable: After the file is written, syntastic will flag errors in the gutter and statusline.
In test-nightly: After the file is written, nothing happens.

Versions installed

uname -a: Linux lampam-ThinkPad-T430 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
rustup: rustup 0.5.0 (4be1012 2016-07-30)
rust.vim: (git hash) 7304385
syntastic: (git hash) aa2a09110956e46652a9cb247ec24a57797066fd
vim: VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 16 2016 10:50:38)

Versions of rustc tested: (OK means syntastic highlights the error)
OK: rustc 1.10.0 (cfcb716cf 2016-07-03)
OK: rustc 1.11.0-beta.3 (052e32bd9 2016-08-08)
FAIL: rustc 1.12.0-nightly (0ef24eed2 2016-08-10)
FAIL: rustc 1.12.0-nightly (8787a1233 2016-08-11)

@ExpHP
Copy link
Author

ExpHP commented Aug 12, 2016

Notice: It also works fine for beta. Only nightly is affected.

@ExpHP
Copy link
Author

ExpHP commented Aug 12, 2016

After further testing I believe the cause is due to the new error format.

This is because, when using override set beta, the following exhibits the issue:

RUST_NEW_ERROR_FORMAT=true vim src/main.rs

while no issue occurs when vim is invoked without the env var.

Edit: Related to #88

@iamsebastian
Copy link

iamsebastian commented Sep 21, 2016

A hint for people, looking for syntax-checking their work on nightly:

While it's not possible to use syntastic with nightly atm., you can check your whole crate / project with snippets like these:

Just parsing:

❯ find ./ | egrep "\.rs$" | xargs -L1 rustc -Z parse-only
#or with silversearcher
❯ ag -g \.rs\$ | xargs -L1 rustc -Z parse-only 

Run all passes without translation:

❯ find ./ | egrep "\.rs$" | xargs -L1 rustc -Z no-trans
#or with silversearcher
❯ ag -g \.rs\$ | xargs -L1 rustc -Z no-trans

@leeola
Copy link

leeola commented Sep 28, 2016

For those wanting to solve this problem with Neomake, the following Maker will solve this issue. A bit verbose, i'm including my docstrings on it.

" create our actual neomake maker for cargo. Note that neomake ships with a
" default maker, but it is not using the new error format which resides in
" nightly.
"
" I'm using an explicit 'cargo' exe name incase i want to change the maker
" name without affecting the binary. `append_file` is used because neomake
" will automatically append the file path to the end of the full command,
" which causes cargo to fail. Finally, the errorformat was pulled from
" a rust.vim PR[1] attempting to fix the problem that causes me to add
" this whole neomake maker. Thanks to them!!
"
" [1]: https://github.com/rust-lang/rust.vim/pull/99#issuecomment-244954595
let g:neomake_rust_cargo_maker = {
    \ 'exe': 'cargo',
    \ 'args': ['build'],
    \ 'append_file': 0,
    \ 'errorformat': '%Eerror%m,%Z\ %#-->\ %f:%l:%c',
  \ }
" Replace the default makers list with our new maker, ensuring our cargo maker
" and not the default maker is what is run when we save.
let g:neomake_rust_enabled_makers = ['cargo']
" Automatically run this maker when we save .rs files.
autocmd! BufWritePost *.rs Neomake cargo

This won't help you if you're looking for Syntastic support, but i quite like Neomake's take on this. Also useful, let g:rustfmt_fail_silently=1 if you want rust.vim not to print rustfmt errors that neomake likely is already displaying.

Even if you prefer Syntastic, this may be a nice temporary measure for some of you :)

@k0pernicus
Copy link

Thank you for this solution, but when I'm using this code and an error using Animals::Rat insteads of Animal::Cat, I only have this error: Neomake: cargo completed with exit code 101.
Do I need to update my neovim configuration code?

Thanks!

@ExpHP
Copy link
Author

ExpHP commented Sep 29, 2016

Hm, looks like I never made a link between this issue and PR #99. (now I have!)

I have been using that branch for a while now and believe it solves the brunt of the issue, so I plan to close this once it goes through. (for any remaining problems I imagine it might be better to raise new issues)

@ExpHP ExpHP closed this as completed Oct 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants