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

Cargo check does not report error: symbol foo is already defined #61330

Closed
mcarton opened this issue May 29, 2019 · 3 comments
Closed

Cargo check does not report error: symbol foo is already defined #61330

mcarton opened this issue May 29, 2019 · 3 comments
Labels
T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@mcarton
Copy link
Member

mcarton commented May 29, 2019

Problem
Some errors are not reported by cargo check.

Steps
For example, here cargo check succeeds:

% cargo check
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
% cat src/main.rs 
#[no_mangle]
fn test() {}

mod foo {
    #[no_mangle]
    fn test() {}
}

fn main() {
    println!("Hello, world!");
}

But cargo build does fail:

% cargo build
   Compiling asdf v0.1.0 (/tmp/asdf)
error: symbol `test` is already defined
 --> src/main.rs:6:5
  |
6 |     fn test() {}
  |     ^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `asdf`.

To learn more, run the command again with --verbose.

Notes

Output of cargo version:

% cargo --version      
cargo 1.34.0 (6789d8a0a 2019-04-01)
% rustc --version
rustc 1.34.2 (6c2484dc3 2019-05-13)
% rustup --version
rustup 1.18.1 (2019-04-26)
@ehuss ehuss transferred this issue from rust-lang/cargo May 29, 2019
@ehuss
Copy link
Contributor

ehuss commented May 29, 2019

Moved to rust-lang/rust.

I think this is to be expected. cargo check performs all steps up to translation. Some errors are only detected during later phases. I don't know if it is feasible to check errors like this.

@jonas-schievink jonas-schievink added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 29, 2019
@mcarton
Copy link
Member Author

mcarton commented May 30, 2019

I understand why it fails, but the intent of cargo check seems to be that if cargo check succeeds, then cargo build will as well, however this is not true, and doesn't seem to be explicitly documented anywhere.

$ cargo check --help
cargo-check 
Check a local package and all of its dependencies for errors

@Mark-Simulacrum
Copy link
Member

I think this is essentially unavoidable -- there's a reason cargo build and cargo check are separate; one can do strictly more error checking than the other. I'm going to close this as not a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants