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

Changing edition makes incremental compilation wrong #19195

Open
Evian-Zhang opened this issue Feb 21, 2025 · 13 comments
Open

Changing edition makes incremental compilation wrong #19195

Evian-Zhang opened this issue Feb 21, 2025 · 13 comments
Labels
C-bug Category: bug

Comments

@Evian-Zhang
Copy link

Evian-Zhang commented Feb 21, 2025

Problem

For a Rust package written and compiled with edition 2021 before, if we do not use cargo clean to remove target directory, and change the edition in Cargo.toml from "2021" to "2024", the compilation cannot report correctly.

Steps

  1. Compile a Rust package of edition 2021 (with some codes that compile in 2021 but not compile in 2024)
  2. Change edition from 2021 to 2024
  3. Compile again, it does not say anything wrong
  4. cargo clean
  5. Compile again. It now correctly reports something is wrong.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.85.0 (d73d2caf9 2024-12-31)
release: 1.85.0
commit-hash: d73d2caf9e41a39daf2a8d6ce60ec80bf354d2a7
commit-date: 2024-12-31
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 22.4.0 (jammy) [64-bit]
@Evian-Zhang Evian-Zhang added the C-bug Category: bug label Feb 21, 2025
@epage
Copy link

epage commented Feb 21, 2025

At first, I wondered if rust-lang/cargo#14973 did this but manifest metatdata did not include the edition. Looking at https://doc.rust-lang.org/nightly/nightly-rustc/cargo/core/compiler/fingerprint/index.html, edition is suppose to be part of the fingerprint through the target.

Target comes from the unit
https://github.com/rust-lang/cargo/blob/1566e4c346b1dd511492e760e9c02a12d6b1f61c/src/cargo/core/compiler/fingerprint/mod.rs#L1559
which comes from the manifest which has edition because that is per target
https://github.com/rust-lang/cargo/blob/1566e4c346b1dd511492e760e9c02a12d6b1f61c/src/cargo/core/manifest.rs#L303

This makes me wonder if this is from the compiler's side of incremental compilation. Granted, this was all done by inspection.

@Evian-Zhang
Copy link
Author

If this is from the compiler's side, should I post this issue in rust main repo?

@weihanglo
Copy link
Member

@Evian-Zhang, do you have a minimal repro?

I've tried this

fn main() {
    let [&x, y] = &[&(), &()];
}

After changing to edition = "2024" the compilation failed as expected.

@Evian-Zhang
Copy link
Author

Oh I finally realize how to reproduce this.

When changing "2021" to "2024", you should keep rust-analyzer running (I use VSCode for this).

The corrected steps are:

  1. Compile a Rust package of edition 2021 (with some codes that compile in 2021 but not compile in 2024)
  2. Open it in VSCode, with rust-analyzer on.
  3. Change edition from 2021 to 2024
  4. Compile again, it does not say anything wrong
  5. cargo clean
  6. Compile again. It now correctly reports something is wrong.

@Evian-Zhang
Copy link
Author

Hmmm, should I post this issue to rust-analyzer instead of here?

@weihanglo
Copy link
Member

I cannot reproduce it in VS Code with bundled rust-analyzer 0.3.2308, nor in neovim with rust-analyzer from 1.85.0. I ran cargo build in embedded terminal in VS Code, with the above reproduction #19195 btw.

Could you clarify how you compile a Rust package? Clear and exact reproducible steps would help.
If possible, try minimizing your code and share with us?

@weihanglo
Copy link
Member

@rustbot transfer rust-analyzer

If it turns out a cargo issue, feel free to transfer it back!

@rustbot rustbot transferred this issue from rust-lang/cargo Feb 21, 2025
@Evian-Zhang
Copy link
Author

Minimal working example:

src/main.rs:

#[no_mangle]
fn foo() {

}

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

Cargo.toml:

[package]
name = "edition-test"
version = "0.1.0"
edition = "2021"

[dependencies]

Step:

  1. Make sure there is no target/ directory
  2. Use cargo check
  3. Open this repository using VSCode with rust-analyzer
  4. After RA finishes, edit Cargo.toml to change 2021 to 2024
  5. After RA finishes, run cargo check, which says everything OK
  6. Use cargo clean
  7. Run cargo check again, now cargo finally realizes something is wrong.

This example is 100% reproducible in my machine.

The RA version is 0.3.2308, cargo version is 1.85.0.

@ShoyuVanilla
Copy link
Member

Could you also share what cargo says in 7.? And does rust-analyzer emit any error while those steps?

@Evian-Zhang
Copy link
Author

Evian-Zhang commented Feb 21, 2025

In 7., cargo check says:

error: unsafe attribute used without unsafe
 --> src/main.rs:1:3
  |
1 | #[no_mangle]
  |   ^^^^^^^^^ usage of unsafe attribute
  |
help: wrap the attribute in `unsafe(...)`
  |
1 | #[unsafe(no_mangle)]
  |   +++++++         +

error: could not compile `edition-test` (bin "edition-test") due to 1 previous error

And for rust-analyzer, it is more subtle:

After I edit Cargo.toml to change 2021 to 2024, and I do not manually "save" the file to trigger RA to recompile (but the file itself does be saved, which can be verified by cat it in commandline), both RA and cargo check say everything is OK. And no matter how many times I "save" the file in Cargo.toml tab, things remains. But when I switch VSCode tab from Cargo.toml to main.rs and manually "save" the main.rs, which triggers the RA to recompile, both RA and cargo check now say the above error.

@weihanglo
Copy link
Member

Confirmed that it is reproducible from also Neovim with the same steps. Not VS Code specific.

When no rust-analyzer involved, i.e., cargo check -> 2021 to 2024 -> cargo check. The second check failed as expected.

@ShoyuVanilla
Copy link
Member

Seems like a filesystem lock or cache problem

@Veykril
Copy link
Member

Veykril commented Feb 21, 2025

Might be the rustc wrapper causing issues again #14722, it at least sounds very like it. Not much we can do about that unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

5 participants