Skip to content

Rebase to e33e3c1 - #385

Open
rubujubi wants to merge 837 commits into
m1from
move-rebase-e33
Open

Rebase to e33e3c1#385
rubujubi wants to merge 837 commits into
m1from
move-rebase-e33

Conversation

@rubujubi

@rubujubi rubujubi commented Jun 25, 2026

Copy link
Copy Markdown
Collaborator

Description

Downstream Aptos pre license change commits from last fork f7a17a6 (on movement) to e33e3c1 (on upstream) onto movement m1.

This PR is created by rebasing onto e33e3c1, and solve the merge conflicts. Mechanical conflicts as explained in the below section has been directly fixed in the merge commit.

Mechanical conflicts — rename/delete resolutions

Group Count Rule applied
.github/{workflows,actions} rename/delete 20 Movement renamed these upstream CI files to .bak (archived); upstream deleted them → kept Movement's .bak
aptos-rosetta removal 6 Movement removed the crate; upstream modified the files → honored deletion (git rm) + a git rm -r crates/aptos-rosetta sweep to catch any upstream re-adds
my_first_dapp example manifests 2 Upstream deleted the example; m1 had bumped deps → followed upstream deletion

Total: 28 rename/delete conflicts

junxzm1990 and others added 30 commits October 11, 2025 19:48
The `values_impl::IntegerValue` type introduced a rather unnecessary wrapper for integer values, creating to conversions back and force to `Value`. Moreover, the newtype wrapper `Value` for `ValueImpl` was unnecessary as well and created
overhead because it cannot be eliminated by the compiler when applied in iterators (as in `values.into_iter().map(Value).collect()`). Both have been removed.
This enables intermediate tools to use `$` in identifiers to separate from user identifiers, e.g. names for public struct functions. This is only supported from bytecode version 9 onwards.

Co-authored-by: Teng Zhang <rahxephon89@163.com>
…__`. (aptos-labs#17854)

* [compiler & language] Support builtin constant `__COMPILE_FOR_TESTING__`.

Allow code to branch over a compile time constant `__COMPILE_FOR_TESTING__`. The non-reachable branch will be optimized (or at least turned into dead code.)

The name is under discussion. We should make the right decision here since any future compile time constants should be following this naming convention. I see compile constants as an equivalent to Rust attributes, at least if it comes to conditional compilation.

This falls into the categorie of builtin constants which we already have for the spec llanguage. At the same time, we would enable `MAX_U64` et. all as builtin constants in the language.

Builtin constants can be shadowed by the user, so no harm to existing move programs would be implied.

* Fully support MIN/MAX for all integer types. Also move unit test out of framework, because it may not compile with older compilers.
Co-authored-by: Igor <igor-aptos@users.noreply.github.com>
Pushed to one node and let it run overnight. Seems like compactions can keep up.
…os-labs#17867)

* OrderBook use of iterators and utilities

* don't use iterators
apenzk and others added 3 commits July 1, 2026 14:19
- thread traversal_context through initialize_governed_gas_pool to match exec_function's updated 7-arg signature
- pass the dealer public key to DefaultDKG::generate_transcript in the rand network_messages test
- switch that test from the removed WeightedConfig name to the concrete WeightedConfigBlstrs alias
@blacksmith-sh

This comment has been minimized.

@blacksmith-sh

This comment has been minimized.

@blacksmith-sh

blacksmith-sh Bot commented Jul 2, 2026

Copy link
Copy Markdown

Found 11 test failures on Blacksmith runners:

Failures

Test View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/bug_bbb75fa.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/call_function.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/diamond_clicker.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/
diamond_clicker_noinline.move
View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/publish_module.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/
randomness_safety.move
View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/smoke_test.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/string_fmt.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/tool_attributes.move View Logs
aptos-transactional-test-harness::tests/runner::aptos_test_harness/
write_set_too_large.move
View Logs
e2e-move-tests/tests::cryptoalgebra::test_deep_type_tag View Logs

Fix in Cursor

@ganymedio

ganymedio commented Jul 7, 2026

Copy link
Copy Markdown

@rubujubi does Movement support orderless / nonce transactions? This PR exposes them in the CLI via --replay-protection-type nonce on run/publish/simulate. Default is seqnum so existing behavior is safe, but this exposes an upstream feature that may not be enabled, so if orderless-txn / payload-v2 isn't actually live on Movement then --replay-protection-type nonce produces transactions the node will reject. Which I think is okay, just something to be aware of.

@ganymedio

ganymedio commented Jul 7, 2026

Copy link
Copy Markdown

A couple things to flag in the SDK:

  1. Dead fields on TransactionFactory (likely a half-carried port). The PR adds two fields — use_txn_payload_v2_format and use_replay_protection_nonce — and a build() branch that consumes them:
payload: if self.use_txn_payload_v2_format || self.use_replay_protection_nonce {
    payload.upgrade_payload_with_fn(...)   // + thread_rng() nonce
} else { port). The PR adds two fields — use_txn_payload_v2_format and use_replay_protection_nonce — and a build() branch that consumes them:
payload: if self.use_txn_payload_v2_format || self.use_replay_protection_nonce {
    payload.upgrade_payload_with_fn(...)   // + thread_rng() nonce
} else {
    payload
},

but there doesn't appear to be a setter for either field. They're hardcoded false in new(), never mutated, and the fields are private so no other crate can set them. The factory's only with_* methods are gas/expiration/chain-id. So the if branch is currently unreachable (always takes the else).

It's not a bug, more like dead weight, just wanted to check that upstream didn't add a builder setter (e.g. a with_payload_v2_format(...)) that maybe didn't get carried through the rebase? Not sure if a factory setter dropped in the merge, or are these fields intentionally inert for now?

  1. get_transaction_expiration_time() can panic. It now does unimplemented!() for the new Absolute expiration variant:
TransactionExpiration::Absolute { .. } => unimplemented!(),

No callers currently, so it's latent, but figured I'd flag for awareness.

@rubujubi
rubujubi marked this pull request as ready for review July 9, 2026 17:37
@rubujubi
rubujubi requested a review from seanyoung July 9, 2026 17:37
@rubujubi

Copy link
Copy Markdown
Collaborator Author

@rubujubi does Movement support orderless / nonce transactions? This PR exposes them in the CLI via --replay-protection-type nonce on run/publish/simulate. Default is seqnum so existing behavior is safe, but this exposes an upstream feature that may not be enabled, so if orderless-txn / payload-v2 isn't actually live on Movement then --replay-protection-type nonce produces transactions the node will reject. Which I think is okay, just something to be aware of.

Thanks, Movement does not support it yet. I think it is fine to leave it here since currently --replay-protection-type nonce will be rejected cleanly

seanyoung
seanyoung previously approved these changes Jul 14, 2026

@seanyoung seanyoung left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I've gone through the merge conflicts and they all look good to me.

The governed gas pool merge moves things around but everything is still there. I will double check once the governed gas pool is ready for merging.

I have to say it painstaking work, I did my best but I hope I did not miss anything.

@areshand

Copy link
Copy Markdown
Collaborator

validated through ephemeral mainnet. The chain is health. let's go ahead and land it.

areshand
areshand previously approved these changes Aug 19, 2026
@areshand

Copy link
Copy Markdown
Collaborator

@rubujubi can you rebase and land this

@seanyoung
seanyoung dismissed stale reviews from areshand and themself via e49af62 September 3, 2026 14:57
@seanyoung
seanyoung requested a review from fEst1ck as a code owner September 3, 2026 14:57
## Description

Renames the GitHub org reference `movementlabsxyz` → `movement-network`
across the
repository, following the org rename. 33 occurrences in 19 files:

- **CI / release automation** — reusable-workflow refs

(`movement-network/aptos-core/.github/actions/build-{binary,container}@m1`),
the
`IMAGE_NAMESPACE`/`image_name` values for the `aptos-node`,
`aptos-debugger` and
`aptos-faucet-service` GHCR images, the `Justfile` build/push targets,
and the
  release-existence probe in `scripts/cli/build_cli_release.sh`.
- **Claude PR audit workflow** — `REVIEWER_REPO:
movement-network/claude-pr-reviewer`
  (`REVIEWER_REF: v1` unchanged).
- **Code constants** — the framework git URL used by `aptos move init`
(`crates/aptos/src/move_tool/mod.rs`) and the shallow-clone URL used for
merge-base
  metadata in `devtools/aptos-cargo-cli/src/common.rs`.
- **Move manifests** — `AptosFramework` git dependency URLs in the
  `movement-migration/*` packages.
- **Release metadata** — `source_code_url` / `discussion_url` in
  `aptos-move/aptos-release-builder/data/release.yaml` and the generated
  `disable_concurrent_fungible_balance.json`.
- **Docs / comments** — homebrew README,
`docker/aptos-debugger/README.md`, and the
  PR link in the `pipelined_block.rs` regression comment.

No functional or behavioral change. GitHub keeps redirects for renamed
orgs, so nothing
was broken before this; the change makes the references match reality.

Incidental formatter noise is included in the same commit (no logic
touched):
`crates/aptos/src/move_tool/mod.rs` struct literals reflowed by rustfmt,
`scripts/cli/build_cli_release.sh` re-indented to tabs,
`build-versions.yaml` quote
style plus trailing-whitespace cleanup, and homebrew README list
indentation.

## How Has This Been Tested?

- `grep -ril movementlabsxyz .` returns zero hits repo-wide.
- Reviewed every hunk by hand to confirm each change is either the org
rename or
  formatter-only.
- CI on this PR exercises the renamed reusable workflows / GHCR
namespace; the
  container publish paths must be confirmed green before merge.

## Key Areas to Review

- **`.github/workflows/build-versions.yaml`** — the `uses:` refs and
`IMAGE_NAMESPACE`
must resolve under the new org and the GH token must still have push
rights to
`ghcr.io/movement-network/*`. This is the one place a wrong value fails
only at
  release time.
- **`.github/workflows/claude-audit-pr.yml`** —
`movement-network/claude-pr-reviewer`
  must exist with tag `v1`.
- **`crates/aptos/src/move_tool/mod.rs` /
`movement-migration/*/Move.toml`** — these URLs
end up in user-facing generated manifests and in migration packages; a
bad URL breaks
  `aptos move init` / package resolution for downstream users.
- **Formatter churn** — if you'd rather keep the rename diff surgical,
say so and I'll
  split the reformatting into a separate commit.

## Type of Change
- [ ] New feature
- [ ] Bug fix
- [ ] Breaking change
- [ ] Performance improvement
- [x] Refactoring
- [ ] Dependency update
- [x] Documentation update
- [ ] Tests

## Which Components or Systems Does This Change Impact?
- [ ] Validator Node
- [ ] Full Node (API, Indexer, etc.)
- [ ] Move/Aptos Virtual Machine
- [ ] Aptos Framework
- [x] Aptos CLI/SDK
- [x] Developer Infrastructure
- [ ] Move Compiler
- [x] Other (CI/CD workflows, container image namespace, release
metadata, migration Move packages)

## Checklist
- [x] I have read and followed the
[CONTRIBUTING](https://github.com/aptos-labs/aptos-core/blob/main/CONTRIBUTING.md)
doc
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I identified and added all stakeholders and component owners
affected by this change as reviewers
- [x] I tested both happy and unhappy path of the functionality
- [x] I have made corresponding changes to the documentation
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.