Merge pull request #775 from multiversx/sc-config-flags-and-no-check-…

…flag-for-upgrade

sc-config flags: codegen-units, opt-level, lto, debug, panic, overflo…

docs/developers/meta/sc-config.md

@@ -40,12 +40,20 @@ allocator = "leaking"
 stack-size = "3 pages"
 features = ["example_feature_1", "example_feature_2"]
 kill-legacy-callback = true
+
+[contracts.main.profile]
+codegen-units = 1
+opt-level = "z"
+lto = true
+debug = false
+panic = "abort"
+overflow-checks = false
 ```
 
 The settings are as follows:
 - `panic-message`
     - “Panic with message” is a feature very useful for debugging. It displays messages from regular Rust panics in a contract, at the cost of ~1.5kB of additional contract size. It is disabled by default, we advise against using it in production.
-    - _values_: `true` | `false
+    - _values_: `true` | `false`
     - _default_: `false`
 - `ei`
     - Configures the post-processor that checks the environment interface (EI) used by the built smart contract.
@@ -82,7 +90,44 @@ The settings are as follows:
     - _default_: `[]`
 - `kill-legacy-callback`
     - The framework has no way of knowing whether or not a certain smart contract variant actually needs the async callback code or not, so in rare situations it is necessary to forcefully remove it.
-    - _values_: `true` | `false
+    - _values_: `true` | `false`
+    - _default_: `false`
+- `codegen-units`
+    - Controls the number of "code generation units" a crate will be split into. Splitting a crate into multiple code generation units can have a significant impact on the compile time and code optimization of the crate.
+    - From our experience it is of no particular impact to smart contract compilation.
+    - _default_: `1`
+- `opt-level`
+    - Controls the level of optimization that Rust will apply to the code during compilation.
+    - By default we run with `s` or `z`, since for smart contracts bytecode size optimization is of the essence.
+    - We also run `wasm-opt` after this optimization phase, so this only refers to part of the optimization.
+    - _values_:
+        - `0`: no optimizations;
+        - `1`: basic optimizations;
+        - `2`: some optimizations;
+        - `3`: all optimizations;
+        - `s`: optimize for binary size;
+        - `z`: optimize for binary size, but also turn off loop vectorization.
+    - _default_: `z`
+- `lto`
+    - Enables link-time optimization for the release profile.
+    - _values_: `true` | `false`
+    - _default_: `true`
+- `debug`
+    - Controls the amount of debug information included in the compiled binary.
+    - This setting is not normally used, since wasm-opt erases any debug information anyway. Use the `build-dbg` to get debug information for the compiled contracts.
+    - _values_: `true` | `false`
+    - _default_: `false`
+- `panic`
+    - Controls how smart contracts handles panics, which are unexpected errors that occur at runtime.
+    - Using `"unwind"` is not tested as it makes little sense in a smart contract.
+    - _values_:
+        - `"unwind"`: unwind the stack in case of a panic;
+        - `"abort"`: terminate the execution in case of a panic.
+    - _default_: `"abort"`
+- `overflow_checks`
+    - Controls whether it performs runtime checks for integer overflow. When enabled, it will insert additional checks into the generated code to detect and prevent integer overflow errors.
+    - Note that overflow checks are normally turned off in production, but are useful when testing. The overflow checks are enabled by default when testing smart contracts using the debugger.
+    - _values_: `true` | `false`
     - _default_: `false`
 
 
@@ -272,7 +317,7 @@ An _external view contract_ has a behavior different from that of a regular cont
     - A list of endpoint names to be added directly to this contract.
     - It bypasses the label system.
     - Can be useful if for some reason labels are missing in code or deemed too cumbersome.
-    - Use the public endpoin names, not the rust function names.
+    - Use the public endpoint names, not the Rust function names.
     - _values_: a list of endpoint names, e.g. `add-labels = ["myEndpoint1", "myEndpoint1"]`
     - _default_: `[]`
 - `labels-for-contracts`

docs/developers/meta/sc-meta-cli.md

@@ -58,7 +58,7 @@ Paramameters:
 - `--ignore`
     - Ignore all directories with these names.
     - _default_: `target`.
-- `--no-abi-git-version
+- `--no-abi-git-version`
     - Skips loading the Git version into the ABI
 - `--target-dir-meta`
     - For the meta crates, allows specifying the target directory where the Rust compiler will build the intermediary files. Sharing the same target directory can speed up building multiple contract crates at once.
@@ -114,6 +114,9 @@ Paramameters:
 - `--to`
     - Overrides the version to upgrade to.
     - _default_: the last released version.
+- `--no-check`
+    - By default `upgrade` compile checks the project after each major version upgrade. This is to allow developers that upgrade multiple versions to address issues with the upgrade before too many such issues get to accumulate. This feature can be turned off by the `--no-check` flag.
+    - _default_: project is compiled.
 
 [comment]: # (mx-context-auto)
 

docs/developers/testing/scenario/concept.md

@@ -36,7 +36,7 @@ Historically, they started out as JSON tests. But writing a lot of JSON by hand
 :::info important
 Nowadays, we think that the JSON scenario format is best used for interoperability and replays, not for writing tests.
 
-There are several ways to generte a scenario JSON file automatically, and we encourage developers to move away from writing them by hand.
+There are several ways to generate a scenario JSON file automatically, and we encourage developers to move away from writing them by hand.
 :::
 
 The greatest benefit of the JSON format is that it is language-agnostic, and so it can be used with any of our backends.

docs/developers/testing/scenario/generating-scenarios.md

@@ -6,7 +6,7 @@ title: Generating scenarios
 
 There are currently several ways to generate scenarios.
 
-The combination of generating and running scenarios is very powerful, since it means tests writtend originally for one system can be run of different systems too.
+The combination of generating and running scenarios is very powerful, since it means tests written originally for one system can be run of different systems too.
 
 This diagram shows all the currently possible paths.
 

docs/developers/testing/testing-overview.md

@@ -19,7 +19,7 @@ The simplest answer would be to test them directly on a blockchain. We advise ag
 But testing on a blockchain can be cumbersome. It's a great way to test a final product, but until our product reaches maturity, we want something else. Our testing solution should be:
 - fast,
 - local,
-- something that can we can automate (continuous integration is important1),
+- something that can we can automate (continuous integration is important),
 - something that we might also debug.
 
 This is what integration tests are for. Conveniently, the MultiversX framework offers the possibility to run and debug smart contracts in a sandboxed environment that immitates a real blockchain. 
@@ -50,7 +50,7 @@ Let's, however, quickly go through all options avialable on MultiversX:
 - On a blockchain:
     - Rust interactor framework;
     - [Any other SDK that can interact with the MultiversX blockchains](/sdk-and-tools/overview);
-    - Launching transactions from the wallet diretly.
+    - Launching transactions from the wallet directly.
 - Integration tests:
     - Black-box tests:
         - Rust,