Proc macros are executed in the wrong working directory

[jonas-schievink]

Reported in #7052 (comment), it seems like proc macros should be executed in the directory containing the invoking crate's main file (lib.rs/main.rs, or whatever would be passed to rustc as the crate root to compile).

[jonas-schievink]

It seems fairly hard to obtain the correct directory, since that requires VFS access, and the compiler crates aren't really supposed to have that (they're mostly supposed to care only about FileId, but that isn't enough here). Since correctly expanding file!() etc. would require breaking through this abstraction anyways, maybe this is fine and needs to be changed anyways? cc @matklad

[edwin0cheng]

We already get the dylib path information from cargo-metadata and can we get crate root directory from that too ?

[jonas-schievink]

We already know the crate root of the invoking crate (the root_file_id in CrateData), but it's stored as a FileId, and the compiler crates aren't supposed to know about actual paths. Seems like we have to make an exception for this, perhaps?

[flodiebold]

I feel like this is a very similar thing as e.g. the env in the CrateData.

[edwin0cheng]

I just reread the bug reported in #7052 (comment) , the actual error is, the proc-macro cannot find the related env CARGO_MANIFEST_DIR variable to use for include!(concat!(..)) and it is fixed in #6820 by @jonas-schievink .

OTOH, what is working directory inside proc-macro in rustc ? And is it stable ?

[bjorn3]

The working directory is whatever cargo chooses when running rustc. In the past this was the working directory cargo was invoked from. It was later changed to the root of the workspace. I don't think there are any explicit guarantees from cargo.

[flodiebold]

Presumably fixed by #11353?