Discussion: stdlibs/stdshim/*.gno #892
Comments
|
I guess I didn't specify it completely, but in #814's design stdshim loses its purpose :) I address the part about precompilation in the second part of the proposal; but essentially I think that calls to native functions in gno code should simply call the Go function in the precompiled version, and if they require a So yes, in the "grand scheme" of things for my native bindings proposal, it would make sense to remove stdshim afterwards, as it wouldn't be used even for precompilation. |
|
Related with #814, I think we should close this issue and focus on the other one, nope? TLDR: we'll have .gno files for each thing in stdlib (injected or not). For gno precompile, I suggest storing generated files in a caching folder like |
@moul agree. Can we keep this issue open for now? I am looking into some other related issues. thanks |
Kouteki
modified the milestones:
🏗4️⃣ test4.gno.land,
🏗4️⃣ test4.gno.land [POST LAUNCH]
github-project-automation
bot
moved this from Backlog
to Done
in 🧙♂️gno.land core team
Merge order: 1. gnolang#1700 2. gnolang#1702 3. gnolang#1695 (this one!) -- review earlier ones first, if they're still open! This PR modifies the Gno transpiler (fka precompiler) to use Gno's standard libraries rather than Go's when performing transpilation. This creates the necessity to transpile Gno standard libraries, and as such support their native bindings. And it removes the necessity for a package like `stdshim`, and a mechanism like `stdlibWhitelist`. - Fixes gnolang#668. Fixes gnolang#1865. - Resolves gnolang#892. - Part of gnolang#814. - Makes gnolang#1475 / gnolang#1576 possible without using hacks like `stdshim`. cc/ @leohhhn @tbruyelle, as this relates to your work ## Why? - This PR enables us to perform Go type-checking across the board, and not use Go's standard libraries in transpiled code. This enables us to _properly support our own standard libraries_, such as `std` but any others we might want or need. - It also paves the way further to go full circle, and have Gno code be transpiled to Go, and then have "compilable" gno code ## Summary of changes - The transpiler has been thoroughly refactored. - The biggest change is described above: instead of maintaing the import paths like `"strconv"` and `"math"` the same (so using Gno's stdlibs in Gno, and Go's in Go), the import paths for standard libraries is now also updated to point to the Gno standard libraries. - Native functions are handled by removing their definitions when transpiling, and changing their call expressions where appropriate. This links the transpiled code directly to their native counterparts. - This removes the necessity for `stdlibWhitelist`. - As a consequence, `stdshim` is no longer needed and has been removed. - Test files are still not "strictly checked": they may reference stdlibs with no matching source, and will not be tested when running with `--gobuild`. This is because packages like `fmt` have no representation in Gno code; they only exist as injections in `tests/imports.go`. I'll fix this eventually :) - The CLI (`gno transpile`) has been changed to reflect the above changes. - Flag `--skip-fmt` has been removed (the result of transpile is always formatted, anyway), and `--gofmt-binary` too, obviously. `gno transpile` does not perform validation, but will gladly provide helpful validation with the `--gobuild` flag. - There is another PR that adds type checking in `gno lint`, without needing to run through the transpilation step first: gnolang#1730 - It now works by default by looking at "packages" rather than individual files. This is necessary so that when performing `transpile` on the `examples` directory, we can skip those where the gno.mod marks the module as draft. These modules make use of packages like "fmt", which because they don't have an underlying gno/go source, cannot be transpiled. - Running with `-gobuild` now handles more errors correctly; ie., all errors not previously captured by the `errorRe` which only matches those pertaining to a specific file/line. - `gnoFilesFromArgs` was unused and as such deleted - `gnomod`'s behaviour was slightly changed. - I am of the opinion that `gno mod download` should not precompile what it downloads; _especially_ to gather the dependencies it has. I've changed it so that it does a `OnlyImports` parse of the file it downloads to fetch additional dependencies Misc: - `Makefile` now contains a recipe to calculate the coverage for `gnovm/cmd/gno`, and also view it via the HTML interface. This is needed as it has a few extra steps (which @gfanton already previously added in the CI). - Realms r/demo/art/gnoface and r/x/manfred_outfmt have been marked as draft, as they depend on packages which are not actually present in the Gno standard libraries. - The transpiler now ignores draft packages by default. - `ReadMemPackage` now also considers Go files. This is meant to have on-chain the code for standard libraries like `std` which have native bindings. We still exclude Go code if it's not in a standard library. - `//go:build` constraints have been removed from standard libraries, as go files can only have one and we already add our own when transpiling ## Further improvements after this PR - Scope understanding in `transpiler` (so call expressions are not incorrectly rewritten) - Correctly transpile gno.mod --------- Co-authored-by: Antonio Navarro Perez <antnavper@gmail.com> Co-authored-by: Miloš Živković <milos.zivkovic@tendermint.com>
Description
Shall we only name the files used by gvm as .gno? and move stdshim out of stdlibs?
https://github.com/gnolang/gno/tree/master/gnovm/stdlibs/stdshim
Files in stdlibs/stdshim are supposed to be temp go files generated from stdlibs/std/*.gno during the pre-compile process.
stdlibs/stdshim.go (not gno) is used to mock gno vm native function interface defined in stdlibs.go during gno precompile process so that precompile can use go build tools to check syntax and import path.
pre-compile and build are for developers to leverage the golang native build tool to check syntax and import during the gno development. GVM does not rely on anything from these optimizations or built outcomes.
The text was updated successfully, but these errors were encountered: