-
Notifications
You must be signed in to change notification settings - Fork 141
Support 20 bytes address #10
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
Conversation
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.
Accepting here since this was approved on the Diem side.
Hi, in our Pontem Network fork of the Move compiler, we use 32 bytes as address length https://github.com/pontem-network/diem/blob/v1.5.1-pre/language/move-core/types/src/account_address.rs#L20. |
/land |
@mkurnikov Yes, this is possible. There's some discussion about using const generics to allow arbitrary address lengths in diem/diem#10015, but the conclusion is that this would be a significant refactoring. To allow 32 byte addresses, the quickest path would be to send another PR mimicking this one that adds an |
💔 Test Failed - ci-test |
/land |
@sblackshear ❗ This PR is still missing approvals, unable to queue for landing |
/land |
💔 Test Failed - ci-test |
@tnowacki There are unit test failures with this PR, but I am unable to reproduce it locally. All tests pass on my Mac. Not sure what's going on? Any insights on what might be happening here? |
|
serde_json = "1.0.64" | ||
|
||
[features] | ||
address20 = [] |
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.
Does this add the feature all the time? I'm confused
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.
No it just defines the feature. To enable it address20
needs to be adde to default
(or explicitly specified when adding the move-core-types dependency)
No idea whats up, rerunning the jobs to see if it was just flakiness? As in general flakiness or just that test. Or if that test is really broken somehow? |
Same test again. Going to try running all tests on my mac and see if maybe it is some config poisoning thing or something between tests |
I'm at a loss. Maybe @tzakian has some CLI related ideas? |
Another possible thought, is your branch on your fork up to date? That is, are main on your fork and main on diem/move equivalent? I have seen some CI flakiness when those aren't in sync |
Yeah I rebased to main today. |
Maybe @bmwill knows someone who can help debug this? |
Only other thing I could imagine, just throwing debugging ideas out here, switch the address from 0x3 to something else for this test (maybe 0x1) just to rule out a bug with the address parsing code |
OK. So I reverted my commit and added some dummy changed (empty lines), and the test still failed. So pretty sure it's not related to my change. |
As a stopgap measure, can you see how the test looks with renaming module A? Or changing the address? There is no reason whatsoever that the two modules need the same name between the two test files |
Renaming it does fix the test failure. But it also kind of changed the semantics of the test (the test seems to be testing the duplicate module name on purpose?) |
I edited the test file so that it can pass. |
/land |
Closes: #10
The current address is hard-coded to be 16 bytes. This works well for Diem, but could be insufficient for other systems. A common requirement is 20 bytes.
This PR adds a feature that gates the size of the address to be either 16 or 20 bytes, and change everywhere this is used to be using the right length.
Basically redo diem/diem#10015 since the repo moved.