style: lint go and markdown

CONTRIBUTING.md

@@ -70,7 +70,7 @@ When proposing an architecture decision for the SDK, please start by opening an
 ## Pull Requests
 
 PRs should be categorically broken up based on the type of changes being made (for example, `fix`, `feat`,
-`refactor`, `docs`, and so on). The *type* must be included in the PR title as a prefix (for example, 
+`refactor`, `docs`, and so on). The *type* must be included in the PR title as a prefix (for example,
 `fix: <description>`). This convention ensures that all changes that are committed to the base branch follow the
 [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
 Additionally, each PR should only address a single issue.

cosmovisor/README.md

@@ -77,11 +77,11 @@ In order to support downloadable binaries, a tarball for each upgrade binary wil
 
 The `DAEMON` specific code and operations (e.g. tendermint config, the application db, syncing blocks, etc.) all work as expected. The application binaries' directives such as command-line flags and environment variables also work as expected.
 
-
 ### Detecting Upgrades
 
 `cosmovisor` is polling the `$DAEMON_HOME/data/upgrade-info.json` file for new upgrade instructions. The file is created by the x/upgrade module in `BeginBlocker` when an upgrade is detected and the blockchain reaches the upgrade height.
 The following heuristic is applied to detect the upgrade:
+
 + When starting, `cosmovisor` doesn't know much about currently running upgrade, except the binary which is `current/bin/`. It tries to read the `current/update-info.json` file to get information about the current upgrade name.
 + If neither `cosmovisor/current/upgrade-info.json` nor `data/upgrade-info.json` exist, then `cosmovisor` will wait for `data/upgrade-info.json` file to trigger an upgrade.
 + If `cosmovisor/current/upgrade-info.json` doesn't exist but `data/upgrade-info.json` exists, then `cosmovisor` assumes that whatever is in `data/upgrade-info.json` is a valid upgrade request. In this case `cosmovisor` tries immediately to make an upgrade according to the `name` attribute in `data/upgrade-info.json`.

db/README.md

@@ -9,23 +9,25 @@ The database interface types consist of objects to encapsulate the singular conn
 ### `DBConnection`
 
 This interface represents a connection to a versioned key-value database. All versioning operations are performed using methods on this type.
-  * The `Versions` method returns a `VersionSet` which represents an immutable view of the version history at the current state.
-  * Version history is modified via the `{Save,Delete}Version` methods.
-  * Operations on version history do not modify any database contents.
+
+* The `Versions` method returns a `VersionSet` which represents an immutable view of the version history at the current state.
+* Version history is modified via the `{Save,Delete}Version` methods.
+* Operations on version history do not modify any database contents.
 
 ### `DBReader`, `DBWriter`, and `DBReadWriter`
 
 These types represent transactions on the database contents. Their methods provide CRUD operations as well as iteration.
-  * Writeable transactions call `Commit` flushes operations to the source DB.
-  * All open transactions must be closed with `Discard` or `Commit` before a new version can be saved on the source DB.
-  * The maximum number of safely concurrent transactions is dependent on the backend implementation.
-  * A single transaction object is not safe for concurrent use.
-  * Write conflicts on concurrent transactions will cause an error at commit time (optimistic concurrency control).
+
+* Writeable transactions call `Commit` flushes operations to the source DB.
+* All open transactions must be closed with `Discard` or `Commit` before a new version can be saved on the source DB.
+* The maximum number of safely concurrent transactions is dependent on the backend implementation.
+* A single transaction object is not safe for concurrent use.
+* Write conflicts on concurrent transactions will cause an error at commit time (optimistic concurrency control).
 
 #### `Iterator`
 
-  * An iterator is invalidated by any writes within its `Domain` to the source transaction while it is open.
-  * An iterator must call `Close` before its source transaction is closed.
+* An iterator is invalidated by any writes within its `Domain` to the source transaction while it is open.
+* An iterator must call `Close` before its source transaction is closed.
 
 ### `VersionSet`
 
@@ -36,4 +38,5 @@ This represents a self-contained and immutable view of a database's version hist
 ### In-memory DB
 
 The in-memory DB in the `db/memdb` package cannot be persisted to disk. It is implemented using the Google [btree](https://pkg.go.dev/github.com/google/btree) library.
-  * This currently does not perform write conflict detection, so it only supports a single open write-transaction at a time. Multiple and concurrent read-transactions are supported.
+
+* This currently does not perform write conflict detection, so it only supports a single open write-transaction at a time. Multiple and concurrent read-transactions are supported.

docs/DOCS_README.md

@@ -6,14 +6,14 @@ If you want to open a PR in Cosmos SDK to update the documentation, please follo
 
 - Translations for documentation live in a `docs/<locale>/` folder, where `<locale>` is the language code for a specific language. For example, `zh` for Chinese, `ko` for Korean, `ru` for Russian, etc.
 - Each `docs/<locale>/` folder must follow the same folder structure within `docs/`, but only content in the following folders needs to be translated and included in the respective `docs/<locale>/` folder:
-   - `docs/basics/`
-   - `docs/building-modules/`
-   - `docs/core/`
-   - `docs/ibc/`
-   - `docs/intro/`
-   - `docs/migrations/`
-   - `docs/run-node/`
-- Each `docs/<locale>/` folder must also have a `README.md` that includes a translated version of both the layout and content within the root-level [`README.md`](https://github.com/cosmos/cosmos-sdk/tree/master/docs/README.md). The layout defined in the `README.md` is used to build the homepage. 
+    - `docs/basics/`
+    - `docs/building-modules/`
+    - `docs/core/`
+    - `docs/ibc/`
+    - `docs/intro/`
+    - `docs/migrations/`
+    - `docs/run-node/`
+- Each `docs/<locale>/` folder must also have a `README.md` that includes a translated version of both the layout and content within the root-level [`README.md`](https://github.com/cosmos/cosmos-sdk/tree/master/docs/README.md). The layout defined in the `README.md` is used to build the homepage.
 - Always translate content living on `master` unless you are revising documentation for a specific release. Translated documentation like the root-level documentation is semantically versioned.
 - For additional configuration options, please see [VuePress Internationalization](https://vuepress.vuejs.org/guide/i18n.html).
 

docs/architecture/adr-043-nft-module.md

@@ -79,9 +79,11 @@ message NFT {
 
 - `class_id` is the identifier of the NFT class where the NFT belongs; _required_
 - `id` is an alphanumeric identifier of the NFT, unique within the scope of its class. It is specified by the creator of the NFT and may be expanded to use DID in the future. `class_id` combined with `id` uniquely identifies an NFT and is used as the primary index for storing the NFT; _required_
+
   ```
   {class_id}/{id} --> NFT (bytes)
   ```
+
 - `uri` is a URL pointing to an off-chain JSON file that contains metadata about this NFT (Ref: [ERC721 standard and OpenSea extension](https://docs.opensea.io/docs/metadata-standards)); _required_
 - `data` is a field that CAN be used by composing modules to specify additional properties for the NFT; _optional_
 
@@ -281,15 +283,13 @@ message QueryClassesResponse {
 }
 ```
 
-
 ### Interoperability
 
 Interoperability is all about reusing assets between modules and chains. The former one is achieved by ADR-33: Protobuf client - server communication. At the time of writing ADR-33 is not finalized. The latter is achieved by IBC. Here we will focus on the IBC side.
 IBC is implemented per module. Here, we aligned that NFTs will be recorded and managed in the x/nft. This requires creation of a new IBC standard and implementation of it.
 
 For IBC interoperability, NFT custom modules MUST use the NFT object type understood by the IBC client. So, for x/nft interoperability, custom NFT implementations (example: x/cryptokitty) should use the canonical x/nft module and proxy all NFT balance keeping functionality to x/nft or else re-implement all functionality using the NFT object type understood by the IBC client. In other words: x/nft becomes the standard NFT registry for all Cosmos NFTs (example: x/cryptokitty will register a kitty NFT in x/nft and use x/nft for book keeping). This was [discussed](https://github.com/cosmos/cosmos-sdk/discussions/9065#discussioncomment-873206) in the context of using x/bank as a general asset balance book. Not using x/nft will require implementing another module for IBC.
 
-
 ## Consequences
 
 ### Backward Compatibility

docs/architecture/adr-044-protobuf-updates-guidelines.md

@@ -37,7 +37,7 @@ On top of Buf's recommendations we add the following guidelines that are specifi
 
 ### Updating Protobuf Definition Without Bumping Version
 
-#### 1. `Msg`s MUST NOT have new fields.
+#### 1. `Msg`s MUST NOT have new fields
 
 When processing `Msg`s, the SDK's antehandlers are strict and don't allow unknown fields in `Msg`s. This is checked by the unknown field rejection in the [`codec/unknownproto` package](https://github.com/cosmos/cosmos-sdk/blob/master/codec/unknownproto).
 
@@ -47,11 +47,11 @@ For this reason, module developers MUST NOT add new fields to existing `Msg`s.
 
 It is worth mentioning that this does not limit adding fields to a `Msg`, but also to all nested structs and `Any`s inside a `Msg`.
 
-#### 2. Non-`Msg`-related Protobuf definitions MAY have new fields.
+#### 2. Non-`Msg`-related Protobuf definitions MAY have new fields
 
 On the other hand, module developers MAY add new fields to Protobuf definitions related to the `Query` service or to objects which are saved in the store. This recommendation follows the Protobuf specification, but is added in this document for clarity.
 
-#### 3. Fields MAY be marked as `deprecated`, and nodes MAY implement a protocol-breaking change for handling these fields.
+#### 3. Fields MAY be marked as `deprecated`, and nodes MAY implement a protocol-breaking change for handling these fields
 
 Protobuf supports the [`deprecated` field option](https://developers.google.com/protocol-buffers/docs/proto#options), and this option MAY be used on any field, including `Msg` fields. If a node handles a Protobuf message with a non-empty deprecated field, the node MAY change its behavior upon processing it, even in a protocol-breaking way. When possible, the node MUST handle backwards compatibility without breaking the consensus (unless we increment the proto version).
 
@@ -60,7 +60,7 @@ As an example, the SDK v0.42 to v0.43 update contained two Protobuf-breaking cha
 - The SDK recently removed support for [time-based software upgrades](https://github.com/cosmos/cosmos-sdk/pull/8849). As such, the `time` field has been marked as deprecated in `cosmos.upgrade.v1beta1.Plan`. Moreover, the node will reject any proposal containing an upgrade Plan whose `time` field is non-empty.
 - The SDK now supports [governance split votes](./adr-037-gov-split-vote.md). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`.
 
-#### 4. Fields MUST NOT be renamed.
+#### 4. Fields MUST NOT be renamed
 
 Whereas the official Protobuf recommendations do not prohibit renaming fields, as it does not break the Protobuf binary representation, the SDK explicitly forbids renaming fields in Protobuf structs. The main reason for this choice is to avoid introducing breaking changes for clients, which often rely on hard-coded fields from generated types. Moreover, renaming fields will lead to client-breaking JSON representations of Protobuf definitions, used in REST endpoints and in the CLI.
 
@@ -70,7 +70,7 @@ TODO, needs architecture review. Some topics:
 
 - Bumping versions frequency
 - When bumping versions, should the SDK support both versions?
-  - i.e. v1beta1 -> v1, should we have two folders in the SDK, and handlers for both versions?
+    - i.e. v1beta1 -> v1, should we have two folders in the SDK, and handlers for both versions?
 - mention ADR-023 Protobuf naming
 
 ## Consequences

docs/core/upgrade.md

@@ -95,7 +95,7 @@ if err != nil {
 if upgradeInfo.Name == "my-plan" && !app.UpgradeKeeper.IsSkipHeight(upgradeInfo.Height) {
 	storeUpgrades := storetypes.StoreUpgrades{
 		// add store upgrades for new modules
-		// Example: 
+		// Example:
 		//    Added: []string{"foo", "bar"},
 		// ...
 	}

docs/migrations/rest.md

@@ -78,4 +78,4 @@ Following the Protocol Buffers migration in v0.40, Cosmos SDK has been set to ta
 
 ## Migrating to gRPC
 
-Instead of hitting REST endpoints as described above, the SDK also exposes a gRPC server. Any client can use gRPC instead of REST to interact with the node. An overview of different ways to communicate with a node can be found [here](../core/grpc_rest.md), and a concrete tutorial for setting up a gRPC client can be found [here](../run-node/txs.md#programmatically-with-go).
+Instead of hitting REST endpoints as described above, the SDK also exposes a gRPC server. Any client can use gRPC instead of REST to interact with the node. An overview of different ways to communicate with a node can be found [here](../core/grpc_rest.md), and a concrete tutorial for setting up a gRPC client can be found [here](../run-node/txs.md#programmatically-with-go).

docs/ru/README.md

@@ -1,3 +1,3 @@
 # Cosmos SDK Documentation (Russian)
 
-A Russian translation of the Cosmos SDK documentation is not available for this version. If you would like to help with translating, please see [Internationalization](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md#internationalization). A `v0.39` version of the documentation can be found [here](https://github.com/cosmos/cosmos-sdk/tree/v0.39.3/docs/ru).
+A Russian translation of the Cosmos SDK documentation is not available for this version. If you would like to help with translating, please see [Internationalization](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md#internationalization). A `v0.39` version of the documentation can be found [here](https://github.com/cosmos/cosmos-sdk/tree/v0.39.3/docs/ru).

docs/run-node/rosetta.md

@@ -8,7 +8,7 @@ The `rosetta` package implements Coinbase's [Rosetta API](https://www.rosetta-ap
 
 ## Add Rosetta Command
 
-The Rosetta API server is a stand-alone server that connects to a node of a chain developed with Cosmos SDK. 
+The Rosetta API server is a stand-alone server that connects to a node of a chain developed with Cosmos SDK.
 
 To enable Rosetta API support, it's required to add the `RosettaCommand` to your application's root command file (e.g. `appd/cmd/root.go`).
 

docs/run-node/run-node.md

@@ -42,6 +42,7 @@ The `~/.simapp` folder has the following structure:
 ## Updating Some Default Settings
 
 If you want to change any field values in configuration files (for ex: genesis.json) you can use `jq` ([installation](https://stedolan.github.io/jq/download/) & [docs](https://stedolan.github.io/jq/manual/#Assignment)) & `sed` commands to do that. Few examples are listed here.
+
 ```bash
 # to change the chain-id
 jq '.chain_id = "testing"' genesis.json > temp.json && mv temp.json genesis.json
@@ -57,6 +58,7 @@ jq '.app_state.mint.minter.inflation = "0.300000000000000000"' genesis.json > te
 ```
 
 ## Adding Genesis Accounts
+
 Before starting the chain, you need to populate the state with at least one account. To do so, first [create a new account in the keyring](./keyring.md#adding-keys-to-the-keyring) named `my_validator` under the `test` keyring backend (feel free to choose another name and another backend).
 
 Now that you have created a local account, go ahead and grant it some `stake` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence:

docs/run-node/run-testnet.md

@@ -6,7 +6,7 @@ order: 7
 
 The `simd testnet` subcommand makes it easy to initialize and start a simulated test network for testing purposes. {synopsis}
 
-In addition to the commands for [running a node](./run-node.html), the `simd` binary also includes a `testnet` command that allows you to start a simulated test network in-process or to initialize files for a simulated test network that runs in a separate process. 
+In addition to the commands for [running a node](./run-node.html), the `simd` binary also includes a `testnet` command that allows you to start a simulated test network in-process or to initialize files for a simulated test network that runs in a separate process.
 
 ## Initialize Files
 

scripts/README.md

@@ -3,10 +3,12 @@ However, some libraries are not Goroutine-safe (e.g. app simulations cannot be r
 and OS-native threading may be more efficient for many parallel simulations, so we use shell scripts here.
 
 ### Validate Gentxs
-A custom utility script is available to [validate gentxs](./validate-gentxs.sh). Though we have 
+
+A custom utility script is available to [validate gentxs](./validate-gentxs.sh). Though we have
 `ValidateBasic()` for validating gentx data, it cannot validate signatures. This custom script helps
 to validate all the gentxs by collecting them one by one and starting a local network.
 It requires the following env settings.
+
 ```shell
 export DAEMON=gaiad
 export CHAIN_ID=cosmoshub-1

simapp/simd/cmd/genaccounts.go

@@ -10,7 +10,6 @@ import (
 
 	"github.com/cosmos/cosmos-sdk/client"
 	"github.com/cosmos/cosmos-sdk/client/flags"
-	"github.com/cosmos/cosmos-sdk/codec"
 	"github.com/cosmos/cosmos-sdk/crypto/keyring"
 	"github.com/cosmos/cosmos-sdk/server"
 	sdk "github.com/cosmos/cosmos-sdk/types"
@@ -40,9 +39,7 @@ contain valid denominations. Accounts may optionally be supplied with vesting pa
 		Args: cobra.ExactArgs(2),
 		RunE: func(cmd *cobra.Command, args []string) error {
 			clientCtx := client.GetClientContextFromCmd(cmd)
-			depCdc := clientCtx.Codec
-			cdc := depCdc.(codec.Codec)
-
+			cdc := clientCtx.Codec
 			serverCtx := server.GetServerContextFromCmd(cmd)
 			config := serverCtx.Config
 
@@ -148,7 +145,7 @@ contain valid denominations. Accounts may optionally be supplied with vesting pa
 
 			appState[authtypes.ModuleName] = authGenStateBz
 
-			bankGenState := banktypes.GetGenesisStateFromAppState(depCdc, appState)
+			bankGenState := banktypes.GetGenesisStateFromAppState(cdc, appState)
 			bankGenState.Balances = append(bankGenState.Balances, balances)
 			bankGenState.Balances = banktypes.SanitizeGenesisBalances(bankGenState.Balances)
 			bankGenState.Supply = bankGenState.Supply.Add(balances.Coins...)

x/auth/spec/05_vesting.md

@@ -621,4 +621,4 @@ all coins at a given time.
 - PeriodicVestingAccount: A vesting account implementation that vests coins
 according to a custom vesting schedule.
 - PermanentLockedAccount: It does not ever release coins, locking them indefinitely.
-Coins in this account can still be used for delegating and for governance votes even while locked.
+Coins in this account can still be used for delegating and for governance votes even while locked.

x/bank/migrations/v044/keys.go

@@ -5,6 +5,6 @@ var (
 )
 
 func CreateAddressDenomPrefix(denom string) []byte {
-	key := append(DenomAddressPrefix, []byte(denom)...)
+	key := append(DenomAddressPrefix, []byte(denom)...) //nolint: gocritic
 	return append(key, 0)
 }

x/bank/migrations/v044/store.go

@@ -79,11 +79,14 @@ func migrateDenomMetadata(store sdk.KVStore) error {
 
 	for ; oldDenomMetaDataIter.Valid(); oldDenomMetaDataIter.Next() {
 		oldKey := oldDenomMetaDataIter.Key()
-		// old key: prefix_bytes | denom_bytes | denom_bytes
-		newKey := append(types.DenomMetadataPrefix, oldKey[:len(oldKey)/2+1]...)
+		l := len(oldKey)/2 + 1
 
+		var newKey = make([]byte, len(types.DenomMetadataPrefix)+l)
+		copy(newKey, types.DenomMetadataPrefix)
+		// old key: prefix_bytes | denom_bytes | denom_bytes
+		newKey = append(newKey, oldKey[:l]...)
 		store.Set(newKey, oldDenomMetaDataIter.Value())
-		oldDenomMetaDataStore.Delete(oldDenomMetaDataIter.Key())
+		oldDenomMetaDataStore.Delete(oldKey)
 	}
 
 	return nil