Model abigen!s Source::Path behaviour after include_str!

[mitchmindtree]

Follow-up to #94.

Currently the path passed to the right hand side argument of abigen! is expected to be relative to the std::env::current_dir:

fuels-rs/fuels-core/src/source.rs

Line 47 in f6d4cc0

let root = env::current_dir()?.canonicalize()?;

This evaluates to whatever happens to be the current directory at the time of macro expansion. This means that the necessary path given to abigen! can change when the project is moved to a different subdirectory of the same workspace, or if its moved from a workspace into its own project, or vice versa. Ideally, we want our src not to be dependent on the directory that the project happens to be executed within.

To fix this, we could model our behaviour after the std include_str! macro. include_str! accepts a path that is relative to the file in which it is invoked. For example if we have:

project/my-contract-abi.json
project/tests/harness.rs

the abigen! macro could then be invoked within the project/tests/harness.rs with

abigen!(MyContract, "../my-contract-abi.json");

[JoshuaBatty]

So I took a look into this. Originally I thought we could use the file!() macro but then we are back to square one with not being able to have a macro evaluate as an input to another macro. Further, the path returned by file!() is where the macro code lives not the file where the macro was called from.

I then started to look at using span to get this information out. Turns out you can use a span to get access to the calling file path, but currently it's an unstable feature. See this open issue

It provides a method on span pub fn source_file(&self) -> SourceFile; This would allow us to get relative paths working, but the issue has been open for over 3 years, so there is a chance it might not land. Still, might be worth periodically checking in to see if there is any movement towards stabilizing this feature.

[JoshuaBatty]

From memory, this needed to be solved in order for us to properly support native Windows builds. This is due to how paths are handled between windows and unix systems. See this tracking issue in the sway repo.

I just re-checked the issue I mentioned above and it seems that this PR just got merged 2 weeks ago that might allow us to move forward here. Might possibly be available in the next rust release.