Regression in the behavior of file!() when using workspaces

[sgrif]

I'm not sure if this is a Rust issue or a Cargo issue, but since it manifests using file!() I figured I'd raise it here. I'm not sure when the actual regression occurred, as it was previously masked in our build by #47139.

The change we're seeing is that file!() is now returning a path relative to the root of the workspace, rather than the root of the project. This specifically breaks our tests which have code like:

let path = Path::new(file!())
    .parent()
    .unwrap()
    .join("other_stuff.txt");
File::open(&path).read_to_string(&mut s).unwrap();

[Mark-Simulacrum]

cc @alexcrichton

[sgrif]

I suspect this is a regression from stable to beta, but I will double check.

[sgrif]

This is a regression from stable to beta, not nightly.

[sgrif]

To reproduce:

Cargo.toml:

[workspace]
members = ["bar"]

cargo new bar

bar/tests/foo.rs:

#[test]
fn test_stuff() {
    assert_eq!("tests/foo.rs", file!());
}

[alexcrichton]

Yes this is an intentional (yet unfortunate) change on behalf of rust-lang/cargo#4788. This has caused a fair bit of unintended breakage, although it's not clear to me whether we should back it out or not regardless (it's fixing a longstanding bug and an underlying reproducibility bug in Cargo).

@sgrif is it possible to update the usage of file!() and such or avoid it entirely?

[sgrif]

Sure, I could hard code the paths. I think that it's a completely reasonable expectation that File::open(file!()) opens the current file, though.

[alexcrichton]

@sgrif just to make sure you understand the ramifications of the existing bug:

• In this example cargo test -p bar from the workspace root fails.

• You get behavior like this:

  cd bar
  cargo test # passes
  cd ..
  cargo test -p bar # passes 
  rm -rf target
  cargo test -p bar # fails
  

• File::open(file!()) only opens the current file if executed from the same cwd, otherwise it fails.

Relying on file!() (because it's relative) is very brittle in general.

[sgrif]

Sure, and we can definitely update Diesel to avoid using it. This seems like unfortunate breakage given the stability guarantees (I know they don't technically apply to Cargo, but I doubt the general Rust user is aware of that)

Relying on file!() (because it's relative) is very brittle in general.

To be honest, I had always assumed it was absolute until I encountered this change.

[alexcrichton]

Er sorry my point is to not say we "definitely should not revert" but rather to point out that this reliance on file!() means that your project is broken today in surprising ways.

We of course have stability guarantees with Cargo, but I figured you may want a heads up regardless to "there may be bugs lurking here" independent of anything.

[sgrif]

Yes, this has definitely made me aware of the issues with it (as have previous cases involving include!, etc)

[Mark-Simulacrum]

@alexcrichton So am I correct that we expect to take no further action on this issue?

[alexcrichton]

@Mark-Simulacrum that is my personal preference, yes. IIRC @rust-lang/cargo discussed this issue in a broader sense but we didn't reach a conclusion.

[alexcrichton]

1.24 has shipped and I don't think this'll get reverted, so closing