-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Stripping --base-path from CLI paths + CLI path normalization (path spec v3) #11408
Comments
Does this also include "default --base-path to current directory"? Otherwise, this would worsen the situation when you use Can you also expand the specification to which logic is applied for the file load callback (or just explain how it behaves wrt base path currently)? |
Good point. I did not take that into account. The default for In that case I think we should treat empty A better solution in my opinion would be to change the default since the ability to use an empty path is just a weird loophole. But that would break importing from absolute paths even before #11410 so I'd go with the special case instead.
Current behavior is very simple: just take the exact string you got on the CLI and use So for example if you give I have updated the spec section to mention the slash conversion. |
The Things that were not implemented or were implemented differently than specified here:
One downside of having this implemented without #11410 is that the normalization may result in absolute paths in cases where the user might not expect them and the user will likely not notice:
|
Implemented by #11545 and ethereum/solc-js#533. |
Closes #4702.
Related to #9353.
Part of a set of issues that replaces #11138.
Abstract
Currently the paths specified on the command line are used directly as source unit names in compiler's virtual filesystem. This means that the paths embedded in contract metadata (and as a consequence also the generated bytecode) can be different depending on where the compiler is invoked from and whether an absolute or a relative path was used. This may lead to problems with reproducing the same bytecode for verification. Another undesirable effect is that when the same file is used in an
import
, its source unit name may be different leading to it being seen by the compiler as a different file and being compiled again (#4702).Many users are not even aware of the distinction between CLI paths and source unit names (see #11263 for a detailed description of how paths/imports work currently) which makes it hard to understand and resolve the resulting issues.
My proposed solution is to always convert paths specified on the CLI to a canonical form and, if possible, make them relative to base path.
Motivation
Let's assume we have
/tmp/contract.sol
with the following content:/tmp/tokens/token.sol
contains:and we compile them with:
token.sol
ends up in the virtual filesystem under three different source unit names even though all the paths refer to the same file in the underlying filesystem:Specification
Paths to files specified on the command line should be processed according to the following rules:
/
../
and../
segments.--base-path
, the path is made relative to that directory.Backwards Compatibility
The change is fully backwards-compatible. It does not change semantics or break any contracts. It also affects only files given on the command line (
--standard-json
remains completely unaffected).Any CLI invocation that worked before will still work but now it may produce slightly different bytecode due to a change in metadata.
The text was updated successfully, but these errors were encountered: