-
Notifications
You must be signed in to change notification settings - Fork 84
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
Normalize abs paths #370
Normalize abs paths #370
Conversation
@@ -151,7 +151,7 @@ def convert_filename( | |||
if not filename.is_absolute(): | |||
filename = cwd.joinpath(filename) | |||
|
|||
absolute = filename | |||
absolute = Path(os.path.abspath(filename)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Key change is here, other changes are just minor additions/fixes to in-line docs
crytic_compile/utils/naming.py
Outdated
@@ -151,7 +151,7 @@ def convert_filename( | |||
if not filename.is_absolute(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this code can be deleted because it is missing a call to resolve()
and the reason this file isn't being found. We should probably favor os.path since it handles symlinks and normalization e.g. here
Nice catch Troy Co-authored-by: alpharush <[email protected]>
In the repro example described by #367, we're searching for eg:
/Users/bohendo/code/github/2023-01-timeswap/node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol
and in
compile_unit.filenames
we saved the absolute path:/Users/bohendo/code/github/2023-01-timeswap/packages/v2-option/../../node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol
The extra
../..
part must have been preventing our saved path from being found, after normalizing the absolute paths, the repro runs to completion w/out error.Uncertain how to write tests for this to prevent regressions, still not 100% sure why this issue didn't arise in our monorepo tests but, in the meantime, this should fix it.