Compling via Terminal Forces the Dependencies to Compile.

[ghost]

Not sure if this is the expected behaviour as it is telling me there is a file lock. I have confirmed that the issue is with this linter, that is, when I disable the linter the problem resolves itself. Not sure if there is anything else I can add.

[colin-kiegel]

@asteriskTheServer Whats your rust version? There is a known problem with rustc 1.12, which is solved with the current stable 1.13, beta and nightly.

[ghost]

@colin-kiegel I am at 1.12 I'll update and see if that resolves my issue.

[White-Oak]

@asteriskTheServer the relevant issue is #77

[ghost]

@White-Oak and @colin-kiegel updating to 1.13 stable did not resolve it for me.

[colin-kiegel]

If you are using rustup or multirust, could you please double check with running rustc -V in your project directory? It's theoretically possible that there is an outdated beta or nightly around..

You are also mentioning a file lock. That might suggest you are running into some concurrency issues. You should not delete the file lock, but wait until linter-rust has finished. That might take a while.

[ghost]

rustc -V outputs rustc 1.13.0 (2c6933acc 2016-11-07)

That might suggest you are running into some concurrency issues.

Maybe? I can try bumping up the amount of threads being used.

You should not delete the file lock, but wait until linter-rust has finished.

I am not deleting the file-lock.

[White-Oak]

Well, I am not able to reproduce that despite using the same rustc version :(

@asteriskTheServer are you sure you do not have any overrides set for that project? You can see all of the overrides, using rustup override list.
Also can you check your linter-rust version in Atom?

@colin-kiegel file lock is being acquired because one cargo is building a project from linter, another is trying to do that from command line, so that is okayish, in a sense that that is supposed to be in a case like this.

[QuietMisdreavus]

Would it be worth putting linter-rust builds into a different target directory so it doesn't clash with the normal builds? That way you wouldn't even need to wait for linter-rust to finish its build to get a terminal build working.

[colin-kiegel]

Ideally the terminal build should benefit from the artifacts generated by linter runs. As long as they are still fresh. In a future with incremental compilation this should become even more significant.

Invalidation due to different compiler flags are probably only edge cases.

@asteriskTheServer please state exactly what commands + arguments you enter in the terminal. The more information the better.

[White-Oak]

@colin-kiegel

Ideally the terminal build should benefit from the artifacts generated by linter runs. As long as they are still fresh

That's what is done in linter-rust 0.7.1! Due to usage of message-format Cargo knows the builds are not really different, and it can reuse build artifacts.

[colin-kiegel]

@White-Oak I know, it was meant as an argument for keeping it in the same directory. The reason I wrote 'ideally' is that it only works well if you don't pass any fancy compiler flags on the command line that invalidate the compilation cache. It's true the linter doesn't do it, but the user still can. Anyway we are sidetracking on the question of @QuietMisdreavus.

[ghost]

Sorry, for the late response, but you know life has a way of getting busy.

@White-Oak rustup override list outputs no overrides and my linter version is 0.7.1

@colin-kiegel I am only using cargo test as my command.

I am currently using cargo version 0.13.0-nightly (eca9e15 2016-11-01) on a fedora 24 machine.

Let me know if their is anything else I can add to help debug.

[colin-kiegel]

@asteriskTheServer What are your linter settings regarding tests and do your tests have
additional dependencies in any way?

[ghost]

@colin-kiegel I have just default settings except that I have cargo comman set to test. The Rustc Build option is unchecked. Sorry not sure what settings you are after. The tests themselves do not have additional dependencies.

[Arcanemagus]

Since the original filer of this issue has deleted their account, and it appears this was something unique to their setup anyway, I'm going to close this issue.