Skip to content
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

[move] Simplify binary version override logic #17718

Merged
merged 3 commits into from
May 15, 2024

Conversation

tzakian
Copy link
Contributor

@tzakian tzakian commented May 13, 2024

Description

The logic around overriding the binary version output by the compiler was spread out over a number of places, and in general was a bit nasty. This simplifies the logic so the version setting happens in only one place in the code base.

Test plan

Make sure existing tests pass.

@tzakian tzakian requested review from cgswords, tnowacki and a team May 13, 2024 23:32
Copy link

vercel bot commented May 13, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
sui-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 15, 2024 11:19pm
3 Ignored Deployments
Name Status Preview Comments Updated (UTC)
multisig-toolkit ⬜️ Ignored (Inspect) Visit Preview May 15, 2024 11:19pm
sui-kiosk ⬜️ Ignored (Inspect) Visit Preview May 15, 2024 11:19pm
sui-typescript-docs ⬜️ Ignored (Inspect) Visit Preview May 15, 2024 11:19pm

@@ -168,7 +165,7 @@ pub fn publish(
let mut serialized_modules = vec![];
for unit in modules_to_publish {
let id = unit.unit.module.self_id();
let module_bytes = unit.unit.serialize(bytecode_version);
let module_bytes = unit.unit.serialize();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not with_version? Is this test only code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a convenience method on CompiledUnit that uses serialize_with_version under the hood, but it's just so you don't need to do the whole let mut bytes = vec![]; unit.unit.module.serialize_with_version(unit.unit.module.version, &mut bytes); bytes. So I kinda liked keeping it. But I can remove if you want it gone completely.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah this is on the compiler's unit, not the CompiledModule?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep! This is on CompiledUnit :)

@@ -168,7 +165,7 @@ pub fn publish(
let mut serialized_modules = vec![];
for unit in modules_to_publish {
let id = unit.unit.module.self_id();
let module_bytes = unit.unit.serialize(bytecode_version);
let module_bytes = unit.unit.serialize();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah this is on the compiler's unit, not the CompiledModule?

}

fn set_module_version(module: &mut CompiledModule, version: Option<u32>) {
if let Some(version) = version.or_else(get_bytecode_version_from_env) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm. Should this be get_bytecode_version_from_env().or(version)?
Or maybe we just nuke get_bytecode_version_from_env since there is a compiler flag?

Copy link
Contributor Author

@tzakian tzakian May 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only reason I kept the env as well is because even though there's a compiler flag the flag is not surfaced up into the package system/the move build command. So if you ever wanted to build a package using the existing workflows and specify the version the only way of doing that is with the env variable (at least currently).

Should this be get_bytecode_version_from_env().or(version)

I went back and forth on this lol and which should override the other if both are set. I'm happy either way so fine switching it around if that's preferable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really care. Let's maybe just focus on propagating that flag and killing get_bytecode_version_from_env

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'll keep get_bytecode_version_from_env at least in this PR since I think there's some nuance that's going to be needed in terms of how we expose the flag out into the build system (i.e., I don't think it should be exposed by default, but maybe only on debug/dev builds etc). Happy to lead the charge on that though (but in a separate PR :) )

Copy link
Contributor

@tnowacki tnowacki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved assuming this takes us closer to killing get_bytecode_version_from_env. If we want to just fully kill it in this PR, we can do that too (just let me take a look before landing :))

@tzakian tzakian force-pushed the tzakian/simplify-binary-version-override-logic branch from df13d18 to 9e67a86 Compare May 15, 2024 23:18
@tzakian tzakian enabled auto-merge (squash) May 15, 2024 23:18
@tzakian tzakian merged commit da718c8 into main May 15, 2024
48 checks passed
@tzakian tzakian deleted the tzakian/simplify-binary-version-override-logic branch May 15, 2024 23:44
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.

None yet

3 participants