Fix inconsistent trailing slash in remappings
Fix #47. One corresponding test is added.
Fix strategy
- Remove the code that blindly add trailing
/when serializingRemappingandRelativeRemapping. - Preserve the trailing
/in thestrip_prefixmethod ofRemapping.
Rationale
There are roughly two sources where Remapping comes from:
- Generated in
find_manyfunction. - Loaded from configuration like
foundry.toml.
When generating Remapping in find_many function, the algorithm makes sure that the name and path of every remapping are valid folders in the file system. Then, trailing /s are added to both name and path in the impl From<RelativeRemapping> for Remapping implementation.
https://github.com/Troublor/compilers/blob/93c5f46a7dd0c0d387dd94c8ea756812e2907d92/src/remappings.rs#L360-L365
When loading Remapping from user-provided configurations, the name and path of remappings should be set as it is, and do not add any trailing /s.
Either way, the field name and path of Remapping contains intended values and should not be changed in the serialization (the implementation for Display trait).
PS: About coding style, I tried to use TempProject to write the test case but it seems the project.compile() method does not respect the remapping I give it via project.with_settings(settings_with_remapping). The remapping just does not take effect in the compilation. Not sure whether it's I don't know how to use it or TempProject has some bugs.
gm @Troublor are you still working on this?
@BlazeWasHere Yeah you remind me. I will finish it this weekend.
ah im not approved for github workflow actions, but locally it doesnt seem to build not sure its because of my system (new pc -- have never used rust on this before) or rust crate incompatibility
edit: it seems like this branch is just missing latest commits from main
The test cases of foundry-rs/compilers (in the CI) seem to indicate there are some problems with Windows. I don't have a Windows machine. Could someone offer some help to look into the issues?
hmm this results in a bunch of failing tests
https://github.com/foundry-rs/foundry/pull/7623
can't proceed with this until sorted out
hmm this results in a bunch of failing tests
can't proceed with this until sorted out
i havent updated my fork yet, can you retrigger ci again now
edit:
https://github.com/foundry-rs/foundry/actions/runs/8672405018/job/23783250651?pr=7623#step:12:316
windows (the bane of oss dev) has missing trailing /
gnu/linux ditto. 😢 https://github.com/foundry-rs/foundry/actions/runs/8672405018/job/23783250255?pr=7623#step:12:153
https://github.com/foundry-rs/foundry/blob/89f0fb923773cf0f8f966290e579bae92f505077/crates/forge/tests/cli/config.rs#L233 seems to fail because of https://github.com/foundry-rs/compilers/blob/66d2677e9257ec6b9aee99ad4ab894375ee6af22/src/remappings.rs#L364-L376
hey @Troublor do you have plans for finishing this?
considering that CI fails I am thinking that perhaps we should take a different approach? currently in remappings.txt of a foundry project you can specify remappings in any format: any of project=src, project=src/, project/=src, etc would get updated to project/=src/ because it's the way conversion RelativeRemapping -> Remapping works:
https://github.com/foundry-rs/compilers/blob/a21275dc8df3514e8b076841a748cecbad60aac2/crates/artifacts/solc/src/remappings.rs#L360-L365
however, when working with i.e. etherscan projects or any sources of remappings requiring deserialization directly into Remapping we don't go through that conversion and validation and name and path are kept as-is.
Thus, I think we can either just update Display impl for Remapping to also push / to name if it's not present (currently we are only pushing it to path): https://github.com/foundry-rs/compilers/blob/a21275dc8df3514e8b076841a748cecbad60aac2/crates/artifacts/solc/src/remappings.rs#L159-L161
Also, we can consider adding this additional logic to serde::Serialize impl which should also work
@klkvr Thanks. I restructured the patch. Please approve the CI tests.
@klkvr I fixed some regression test oracles. Please trigger CI again. Thx.
@klkvr There seems to be some race: the last commit (just some refactoring) is not included in the CI. But the previous CI passes, so everything should look good now. Thanks for your efforts.
@Troublor mind updating patch in https://github.com/foundry-rs/foundry/pull/7623? (or creating a new PR if you don't have access to that branch)
@klkvr It seems @BlazeWasHere has already updated that PR.
@klkvr I created another PR to test on foundry: https://github.com/foundry-rs/foundry/pull/8377
Foundry would need a little patch as well for one integration test: can_extract_config_values: The expected value of remapping name should have a trailing slash.
Other than this, all tests pass and everything looks good.
@Troublor nice! does this solve the initial issue you had in #47 with compiling contract from Etherscan? If so, I think this is good to merge
@Troublor nice! does this solve the initial issue you had in #47 with compiling contract from Etherscan? If so, I think this is good to merge
I think the original issue is solved after this patch.
@klkvr Yes, problem solved. Thx.