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

Incremental Compilation needs to rebuild everything when feature gates are changed #47820

Closed
oberien opened this issue Jan 28, 2018 · 7 comments
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@oberien
Copy link
Contributor

oberien commented Jan 28, 2018

Given this example:

main.rs

#![feature(nll)]

mod foo;

fn main() {
    foo::foo();
}

foo.rs

pub fn foo() -> Vec<usize> {
    let mut vec = Vec::new();
    vec.push(vec.len());
    vec
}

Without the feature gate nll, foo::foo won't compile, because vec is borrowed by vec.push which doesn't allow vec.len to borrow it again. With nll, this is solved and the code compiles.
With the annotation in main.rs, cargo build will build everything just fine.
After a successful build if we remove #[feature(nll)] and execute cargo build again, everything still compiles, even though it shouldn.

I think that this is due to incremental compilation. Cargo reuses the old module foo instead of recompiling it. If it would recompile it (e.g. after adding a newline to the end of foo.rs), the build breaks as expected.

@TimNN TimNN added A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. labels Jan 30, 2018
@alexcrichton
Copy link
Member

cc @michaelwoerister

@oberien thanks for the report! I think this is a rustc issue because Cargo is reinvoking the compiler, but it looks like stale results may be getting used by incremental compilation?

@alexcrichton alexcrichton added I-nominated T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 30, 2018
@nikomatsakis
Copy link
Contributor

We should probably include the features in the hash of command line options that we give, I guess.

@nikomatsakis
Copy link
Contributor

triage: P-medium

@rust-highfive rust-highfive added P-medium Medium priority and removed I-nominated labels Feb 8, 2018
@nikomatsakis
Copy link
Contributor

Well, I'll triage as P-high just to make sure @michaelwoerister sees this.

triage: P-high

@rust-highfive rust-highfive added P-high High priority and removed P-medium Medium priority labels Feb 8, 2018
@michaelwoerister
Copy link
Member

This is a duplicate of #47003.

@nikomatsakis
Copy link
Contributor

Shall we close it then, @michaelwoerister ?

@michaelwoerister
Copy link
Member

Yes, closing as duplicate. Moving over the P-high tag to the original.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. P-high High priority 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

6 participants