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

[Compiler-v2] fix receiver call with index notation #15239

Merged
merged 5 commits into from
Nov 13, 2024
Merged

Conversation

rahxephon89
Copy link
Contributor

@rahxephon89 rahxephon89 commented Nov 8, 2024

Description

This PR fixes

  1. field selection after resource and vector indexing for receiver call of which the first argument is mutable reference. The following code can pass compilation:
module 0x42::m {
    struct S has key, drop { t: T }

    struct T has store, drop {
        w: W
    }

    struct W has store, drop {
        x: u64
    }

    fun merge(self: &mut W, s: W) {
        self.x += s.x;
    }

    fun foo(account: address, w: W) acquires S {
        S[account].t.w.merge(w)
    }

    fun boo(v: vector<S>, w: W) {
        v[0].t.w.merge(w)
    }

  1. for a function call taking the form A[...].foo(&) or A[...].foo(&mut), translate A[...] into a reference directly so that it behaves like (&A[...]).foo(...) or (&mut A[...]).foo(...).

Close #15224

How Has This Been Tested?

Key Areas to Review

  1. existing test cases;
  2. added new test cases.

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Performance improvement
  • Refactoring
  • Dependency update
  • Documentation update
  • Tests

Which Components or Systems Does This Change Impact?

  • Validator Node
  • Full Node (API, Indexer, etc.)
  • Move/Aptos Virtual Machine
  • Aptos Framework
  • Aptos CLI/SDK
  • Developer Infrastructure
  • Move Compiler
  • Other (specify)

Checklist

  • I have read and followed the CONTRIBUTING doc
  • I have performed a self-review of my own code
  • 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
  • I tested both happy and unhappy path of the functionality
  • I have made corresponding changes to the documentation

Copy link

trunk-io bot commented Nov 8, 2024

⏱️ 2h 18m total CI duration on this PR
Slowest 15 Jobs Cumulative Duration Recent Runs
execution-performance / single-node-performance 22m 🟩
rust-targeted-unit-tests 18m 🟩
rust-cargo-deny 14m 🟥🟩🟩🟩 (+2 more)
rust-move-tests 10m 🟩
rust-move-tests 9m 🟩
rust-move-tests 9m 🟩
rust-move-tests 9m 🟩
rust-move-tests 9m 🟩
check-dynamic-deps 8m 🟩🟩🟩🟩🟩 (+2 more)
rust-doc-tests 5m 🟩
semgrep/ci 4m 🟩🟩🟩🟩🟩 (+2 more)
execution-performance / test-target-determinator 4m 🟩
test-target-determinator 4m 🟩
check 4m 🟩
general-lints 4m 🟩🟩🟩🟩🟩 (+1 more)

settingsfeedbackdocs ⋅ learn more about trunk.io

@rahxephon89 rahxephon89 changed the title [Compiler-v2][WIP] fix field selection after indexing for receiver call [Compiler-v2] fix field selection after indexing for receiver call Nov 8, 2024
@rahxephon89 rahxephon89 marked this pull request as ready for review November 8, 2024 04:44
"receiver call needs to have at least one parameter"
);
let receiver_call_opt = self.get_receiver_function(&arg_types[0], name);
if let (Some(receiver_call), Exp_::ExpDotted(dotted)) =
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we add a test case where receiver_call_opt would be None? When I tried this out, we get a "unknown receiver function" error, but might be good to have a test to prevent any regressions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a test case to calls_index_errors.move.

Copy link
Contributor

@brmataptos brmataptos left a comment

Choose a reason for hiding this comment

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

Do we have a test somewhere for x[i].call() with mutable self parameter?

@rahxephon89
Copy link
Contributor Author

Do we have a test somewhere for x[i].call() with mutable self parameter?

I have tested this case but will add a test case

@rahxephon89
Copy link
Contributor Author

@vineethk @brmataptos, I need another round review for handling x[i].call(&...), thanks!

@rahxephon89 rahxephon89 changed the title [Compiler-v2] fix field selection after indexing for receiver call [Compiler-v2] fix receiver call with index notation Nov 13, 2024
translated_args[0] = first_arg.into_exp();
}
} else if let Exp_::Index(target, index) = &args[0].value {
// special case for the receiver call S[x].fun(&...)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// special case for the receiver call S[x].fun(&...)
// special case for the receiver call `S[x].fun(&...)` and `S[x].fun(&mut...)`

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

let receiver_call_opt = self.get_receiver_function(&arg_types[0], name);
if let Some(receiver_call) = receiver_call_opt {
if let Exp_::ExpDotted(dotted) = &args[0].value {
// special case for the receiver call S[x].f.fun(&mut...)
Copy link
Contributor

Choose a reason for hiding this comment

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

Would be useful to add some note on why these special cases are needed (e.g., we resolve X before doing Y translation), for future refactors/bug fixes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

}

fun foo_2(account: address, w: W) acquires W {
W[account].merge(w)
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add the following test case (or similar) that tests:

  1. Non-mut ref receiver over resource indexing
  2. Resource indexing on a generic type that goes through the newly added translation.
    struct Wrapper<T> has drop, key, store, copy {
        inner: T
    }

    fun unwrap<T>(self: &Wrapper<T>): T {
        self.inner
    }

    fun dispatch<T>(account: address): T acquires Wrapper {
        Wrapper<T>[account].unwrap()
    }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@rahxephon89 rahxephon89 enabled auto-merge (squash) November 13, 2024 22:55

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

✅ Forge suite realistic_env_max_load success on 572ac4df602996cf88d0388ceeda1c378d831f5f

two traffics test: inner traffic : committed: 14493.64 txn/s, latency: 2744.30 ms, (p50: 2700 ms, p70: 2700, p90: 3000 ms, p99: 3100 ms), latency samples: 5510880
two traffics test : committed: 99.97 txn/s, latency: 1496.51 ms, (p50: 1300 ms, p70: 1400, p90: 1500 ms, p99: 11500 ms), latency samples: 1840
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 2.041, avg: 1.482", "ConsensusProposalToOrdered: max: 0.331, avg: 0.293", "ConsensusOrderedToCommit: max: 0.367, avg: 0.354", "ConsensusProposalToCommit: max: 0.657, avg: 0.647"]
Max non-epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.91s no progress at version 2010101 (avg 0.20s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 8.46s no progress at version 2010099 (avg 7.71s) [limit 15].
Test Ok

Copy link
Contributor

✅ Forge suite framework_upgrade success on ea6e45f0eee4b6da2ebf93b9b89d269d334fcf70 ==> 572ac4df602996cf88d0388ceeda1c378d831f5f

Compatibility test results for ea6e45f0eee4b6da2ebf93b9b89d269d334fcf70 ==> 572ac4df602996cf88d0388ceeda1c378d831f5f (PR)
Upgrade the nodes to version: 572ac4df602996cf88d0388ceeda1c378d831f5f
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1487.62 txn/s, submitted: 1489.88 txn/s, failed submission: 2.26 txn/s, expired: 2.26 txn/s, latency: 2066.70 ms, (p50: 2100 ms, p70: 2100, p90: 2700 ms, p99: 4100 ms), latency samples: 131660
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1603.75 txn/s, submitted: 1607.03 txn/s, failed submission: 3.27 txn/s, expired: 3.27 txn/s, latency: 2124.70 ms, (p50: 2100 ms, p70: 2400, p90: 3000 ms, p99: 3900 ms), latency samples: 127380
5. check swarm health
Compatibility test for ea6e45f0eee4b6da2ebf93b9b89d269d334fcf70 ==> 572ac4df602996cf88d0388ceeda1c378d831f5f passed
Upgrade the remaining nodes to version: 572ac4df602996cf88d0388ceeda1c378d831f5f
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1313.60 txn/s, submitted: 1316.04 txn/s, failed submission: 2.44 txn/s, expired: 2.44 txn/s, latency: 2287.62 ms, (p50: 2100 ms, p70: 2400, p90: 3300 ms, p99: 5100 ms), latency samples: 118380
Test Ok

Copy link
Contributor

✅ Forge suite compat success on ea6e45f0eee4b6da2ebf93b9b89d269d334fcf70 ==> 572ac4df602996cf88d0388ceeda1c378d831f5f

Compatibility test results for ea6e45f0eee4b6da2ebf93b9b89d269d334fcf70 ==> 572ac4df602996cf88d0388ceeda1c378d831f5f (PR)
1. Check liveness of validators at old version: ea6e45f0eee4b6da2ebf93b9b89d269d334fcf70
compatibility::simple-validator-upgrade::liveness-check : committed: 15199.17 txn/s, latency: 2165.29 ms, (p50: 1900 ms, p70: 2000, p90: 2400 ms, p99: 7900 ms), latency samples: 581300
2. Upgrading first Validator to new version: 572ac4df602996cf88d0388ceeda1c378d831f5f
compatibility::simple-validator-upgrade::single-validator-upgrading : committed: 7585.45 txn/s, latency: 3818.08 ms, (p50: 4300 ms, p70: 4400, p90: 4500 ms, p99: 4700 ms), latency samples: 143200
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 6791.84 txn/s, latency: 4617.95 ms, (p50: 4600 ms, p70: 4700, p90: 6600 ms, p99: 6900 ms), latency samples: 254760
3. Upgrading rest of first batch to new version: 572ac4df602996cf88d0388ceeda1c378d831f5f
compatibility::simple-validator-upgrade::half-validator-upgrading : committed: 7709.90 txn/s, latency: 3527.87 ms, (p50: 3700 ms, p70: 4200, p90: 4800 ms, p99: 5000 ms), latency samples: 138440
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 7900.90 txn/s, latency: 4053.57 ms, (p50: 4100 ms, p70: 4300, p90: 6200 ms, p99: 6400 ms), latency samples: 261800
4. upgrading second batch to new version: 572ac4df602996cf88d0388ceeda1c378d831f5f
compatibility::simple-validator-upgrade::rest-validator-upgrading : committed: 11807.47 txn/s, latency: 2327.63 ms, (p50: 2400 ms, p70: 2600, p90: 3000 ms, p99: 3200 ms), latency samples: 205640
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 11814.88 txn/s, latency: 2640.82 ms, (p50: 2600 ms, p70: 2700, p90: 2900 ms, p99: 3000 ms), latency samples: 385220
5. check swarm health
Compatibility test for ea6e45f0eee4b6da2ebf93b9b89d269d334fcf70 ==> 572ac4df602996cf88d0388ceeda1c378d831f5f passed
Test Ok

@rahxephon89 rahxephon89 merged commit 6641f43 into main Nov 13, 2024
82 of 92 checks passed
@rahxephon89 rahxephon89 deleted the teng/fix-15224 branch November 13, 2024 23:28
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.

[compiler-v2] Field selection after resource indexing not mutable
3 participants