Skip to content

Conversation

lxfind
Copy link
Contributor

@lxfind lxfind commented Jan 13, 2022

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.

sblackshear
sblackshear previously approved these changes Jan 13, 2022
Copy link
Contributor

@sblackshear sblackshear left a 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.

bmwill
bmwill previously approved these changes Jan 13, 2022
@mkurnikov
Copy link
Contributor

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.
Is it possible to add even more configurability to this value?

@sblackshear
Copy link
Contributor

/land

bors-libra pushed a commit that referenced this pull request Jan 20, 2022
@sblackshear
Copy link
Contributor

sblackshear commented Jan 20, 2022

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. Is it possible to add even more configurability to this value?

@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 address32 feature. But would also be very happy (happier, in fact!) to support a PR performing the refactoring required to enable full configurability.

@bors-libra
Copy link

💔 Test Failed - ci-test

@lxfind lxfind dismissed stale reviews from bmwill and sblackshear via 69e4e59 January 21, 2022 00:02
@sblackshear
Copy link
Contributor

/land

@bors-libra
Copy link

@sblackshear ❗ This PR is still missing approvals, unable to queue for landing

sblackshear
sblackshear previously approved these changes Jan 21, 2022
@sblackshear
Copy link
Contributor

/land

bors-libra pushed a commit that referenced this pull request Jan 21, 2022
@bors-libra
Copy link

💔 Test Failed - ci-test

@lxfind
Copy link
Contributor Author

lxfind commented Jan 21, 2022

@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?

@tnowacki
Copy link
Contributor

@lxfind

  1. This test is weird and duplicates a module for no reason
  2. Let me check you your branch and take a look

serde_json = "1.0.64"

[features]
address20 = []
Copy link
Contributor

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

Copy link
Contributor Author

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)

@tnowacki
Copy link
Contributor

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?

@tnowacki
Copy link
Contributor

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

@tnowacki
Copy link
Contributor

I'm at a loss. Maybe @tzakian has some CLI related ideas?

@tnowacki
Copy link
Contributor

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

@lxfind
Copy link
Contributor Author

lxfind commented Jan 21, 2022

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.

@tnowacki
Copy link
Contributor

Maybe @bmwill knows someone who can help debug this?

@tnowacki
Copy link
Contributor

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

@lxfind
Copy link
Contributor Author

lxfind commented Jan 21, 2022

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.

@tnowacki
Copy link
Contributor

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

@lxfind
Copy link
Contributor Author

lxfind commented Jan 21, 2022

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?)

@lxfind
Copy link
Contributor Author

lxfind commented Jan 21, 2022

I edited the test file so that it can pass.
Filed issue #22 to track the broken test.

tnowacki
tnowacki previously approved these changes Jan 21, 2022
@tnowacki
Copy link
Contributor

/land

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants