Merge pull request #25008 from NicoSerranoP/patch-1

Update direct binding from sol to go using abigen

docs/_dapp/native-bindings.md

@@ -13,7 +13,7 @@ the direction of the Mist browser, through which users can interact with the blo
 
 Although this was a solid plan for mainstream adoption and does cover quite a lot of use
 cases that people come up with (mostly where people manually interact with the blockchain),
-it eludes the server side (backend, fully automated, devops) use cases where JavaScript is
+it excludes the server side (backend, fully automated, devops) use cases where JavaScript is
 usually not the language of choice given its dynamic nature.
 
 This page introduces the concept of server side native Dapps: Go language bindings to any
@@ -332,29 +332,28 @@ Pending name: Contracts in Go!!!
 
 ## Bind Solidity directly
 
-If you've followed the tutorial along until this point you've probably realized that
+In the past, abigen allowed you to compile and bind a Solidity source file directly to a Go package.
-every contract modification needs to be recompiled, the produced ABIs and bytecodes
+This feature has been discontinued from [v1.10.18](https://github.com/ethereum/go-ethereum/releases/tag/v1.10.18)
-(especially if you need multiple contracts) individually saved to files and then the
+onwards due to maintenance synchronization challenges with the compiler in ```go-ethereum```. 
-binding executed for them. This can become a quite bothersome after the Nth iteration,
+Now, to bind a Solidity source file into a go package you will have to compile it first using 
-so the `abigen` command supports binding from Solidity source files directly (`--sol`),
+any of your prefered approaches (e.g. [solc](https://docs.soliditylang.org/en/v0.8.14/installing-solidity.html) 
-which first compiles the source code (via `--solc`, defaulting to `solc`) into it's
+or [Remix](https://remix.ethereum.org/)) and bind it later. Binding the official Token contract [`token.sol`](https://gist.github.com/karalabe/08f4b780e01c8452d989) would then entail to running:
-constituent components and binds using that.
-
-Binding the official Token contract [`token.sol`](https://gist.github.com/karalabe/08f4b780e01c8452d989)
-would then entail to running:
-
 ```
-$ abigen --sol token.sol --pkg main --out token.go
+$ solc --abi --bin token.sol -o tokenDirectory
+$ abigen --abi tokenDirectory/token.abi --bin tokenDirectory/token.bin --pkg main --type token --out token.go
 ```
 
-*Note: Building from Solidity (`--sol`) is mutually exclusive with individually setting
+You can use the ```solc``` compiler to get a single ```.json``` file containing ABI and bytecode, and then use
-the bind components (`--abi`, `--bin` and `--type`), as all of them are extracted from
+it as input to ```abigen``` to generate the Go package in a shorter command:
-the Solidity code and produced build results directly.*
+```
+$ solc token.sol --combined-json abi,bin -o .
+$ abigen --combined-json combined.json --pkg main --type token --out token.go
+```
 
-Building a contract directly from Solidity has the nice side effect that all contracts
+Even you can combine these two steps together as a pipeline
-contained within a Solidity source file are built and bound, so if your file contains many
+```
-contract sources, each and every one of them will be available from Go code. The sample
+solc token.sol --combined-json abi,bin | abigen --pkg main --type token --out token.go --combined-json -
-Token solidity file results in [`token.go`](https://gist.github.com/karalabe/c22aab73194ba7da834ab5b379621031).
+```
 
 ### Project integration (i.e. `go generate`)