Skip to content

docs: fix typos in README, CLI help, and public identifiers#24

Closed
Gy-Hu wants to merge 1 commit into
BitsLabSec:masterfrom
Gy-Hu:docs/fix-typos
Closed

docs: fix typos in README, CLI help, and public identifiers#24
Gy-Hu wants to merge 1 commit into
BitsLabSec:masterfrom
Gy-Hu:docs/fix-typos

Conversation

@Gy-Hu

@Gy-Hu Gy-Hu commented Apr 24, 2026

Copy link
Copy Markdown

Pure typo cleanup. No behavioral changes; cargo check --workspace and cargo build -p movy --release both pass.

User-facing strings

Where Before After
Readme.md Contributions heading Contritubions Contributions
Readme.md Credits sentence Belobog is inspired by several pioneering projects: Movy is inspired by several pioneering projects: (the list below includes Belobog itself as an inspiration for Movy)
Readme.md + test-data/counter/tests/movy.move Increment does not correctly inreases internal value. ... correctly increases ...
movy sui fuzz --help Ouput directory to save all contents Output directory to save all contents
movy sui fuzz error msg when output dir exists pass -f or env MOVY_FORCE_REMOVAl to always remove it ... MOVY_FORCE_REMOVAL ... (the env var itself, declared on the same arg, was already spelled correctly)
movy-replay log line Commiting movy_init effects... Committing movy_init effects...

Public identifier renames

Mechanical, rustc-verified:

  • FunctionData.return_paramters -> return_parameters (definition in crates/movy-types/src/abi.rs, 17 call sites across movy-types, movy-analysis, movy-fuzz)
  • movy::analysis::AnlaysisArgs -> AnalysisArgs (crates/movy/src/main.rs and crates/movy/src/analysis/mod.rs, 4 sites)

These are the only two misspelled public identifiers I found in the master tree. Both appear in read-a-lot files (abi.rs is the function-ABI definition; main.rs is the CLI entry).

Scope intentionally kept narrow

Test plan

  • cargo check --workspace
  • cargo build -p movy --release
  • movy sui fuzz --help prints "Output directory"
  • Error path for existing output dir prints "MOVY_FORCE_REMOVAL"

User-facing strings:
- README: "Contritubions" -> "Contributions", "Belobog is inspired"
  -> "Movy is inspired" (the surrounding list is the set of projects
  Movy was inspired by, including Belobog itself), and "inreases"
  inside the counter test snippet
- test-data/counter/tests/movy.move: matching "inreases" -> "increases"
- movy sui fuzz --help: "Ouput directory" -> "Output directory"
- movy sui fuzz error message: "MOVY_FORCE_REMOVAl" -> "MOVY_FORCE_REMOVAL"
  (the actual env var, defined on the same arg, was already spelt
  correctly)
- movy-replay: "Commiting movy_init effects..." -> "Committing ..."

Public identifiers (mechanical rename, rustc-verified):
- FunctionData.return_paramters -> return_parameters (17 call sites
  across movy-types, movy-analysis, movy-fuzz)
- movy/src/analysis::AnlaysisArgs -> AnalysisArgs (4 sites in
  movy/src/main.rs and movy/src/analysis/mod.rs)

cargo check --workspace is clean; cargo build -p movy --release
builds; `movy sui fuzz --help` and the existing-output-dir error
path print the corrected strings.
@wtdcode

wtdcode commented May 7, 2026

Copy link
Copy Markdown
Contributor

Hi! Sorry for late.

Would you mind checking if https://github.com/BitsLabSec/movy/tree/v1.65.2-pending covers your PR and #23 ?

@Gy-Hu

Gy-Hu commented May 26, 2026

Copy link
Copy Markdown
Author

Thanks for checking.

I took another look at v1.65.2-pending. If the goal is to cover the behavioral issue from #23 / #21, I don’t think it is fully covered yet. In the current branch, crates/movy-fuzz/src/mutators/sequence/append.rs still has the same panic path for conflicting type arguments:

panic!("Conflicting type arguments for index {}", i);

and the adjacent unwrap/panic paths that #23 relaxed also still seem to be present. Maybe there is another change in v1.65.2-pending that makes this path unreachable, but I could not confirm that from the code.

For #24, most of it is typo/public identifier cleanup, so I understand if that is not the main concern for this branch. I did notice those typo fixes are not included yet, but they can be handled separately if you prefer.

Since these PRs don’t seem to be aligned with the current development focus, I’ll close them for now. If they become useful later, I’m happy to reopen/rebase/split them as needed.

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.

2 participants