-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Dependency in workspace not recompiled after compiler version change #2897
Comments
I’ve experienced a similar problem. After updating the compiler, I tried to run the tests in the nested crate, and I got the following error:
I believe it should have been automatically recompiled. |
Thanks for the report! After investigating I've concluded that this is a dupe of #2897, so I'm going to close in favor of that. |
@alexcrichton looks like you linked back to this issue 😄 what is the dupe number? |
Gah sorry about that! I meant to link to #2855 |
Previously Cargo would compile a library into a different location depending on whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's reliance on the idea of a "root crate" this PR is the next step. With workspaces the root crate of a compliation changes all the time, so the output needs to be the same whether a crate is at the root or not. Fixing this inconsistence in turn fixes bugs like rust-lang#2855 and rust-lang#2897 which arise due to this discrepancy. Additionally, Cargo will no longer recompile a library when it's used as a "root crate" or not. This is fixed by taking a few steps: * Everything is now compiled into the `deps` directory, regardless of whether it's a root output or not. * If a "root crate" is being compiled, then the relevant outputs are hard-linked up one level to where they are today. This means that your binaries, dylibs, staticlibs, etc, will all show up where they used to. * The `-C metadata` flag is always omitted for path dependencies now. These dependencies are always path dependencies and already all have unique crate names. Additionally, they're the only crates in the DAG without metadata, so there's no need to provide additional metadata. This in turn means that none of the file names of the generated crates are mangled. Closes rust-lang#2855
Always build libraries into the same location Previously Cargo would compile a library into a different location depending on whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's reliance on the idea of a "root crate" this PR is the next step. With workspaces the root crate of a compliation changes all the time, so the output needs to be the same whether a crate is at the root or not. Fixing this inconsistence in turn fixes bugs like #2855 and #2897 which arise due to this discrepancy. Additionally, Cargo will no longer recompile a library when it's used as a "root crate" or not. This is fixed by taking a few steps: * Everything is now compiled into the `deps` directory, regardless of whether it's a root output or not. * If a "root crate" is being compiled, then the relevant outputs are hard-linked up one level to where they are today. This means that your binaries, dylibs, staticlibs, etc, will all show up where they used to. * The `-C metadata` flag is always omitted for path dependencies now. These dependencies are always path dependencies and already all have unique crate names. Additionally, they're the only crates in the DAG without metadata, so there's no need to provide additional metadata. This in turn means that none of the file names of the generated crates are mangled. Closes #2855
Steps to reproduce
rustup
, etc.)You should get an error
found crate "member" compiled by an incompatible version of rustc
.Expected behavior
The dependency is recompiled using the new compiler.
You can see this error happening in the rust-rosetta CI here. It seems that the artifacts in the cache were compiled with an older nightly, so the compilation failed.
The text was updated successfully, but these errors were encountered: