-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: remove import cycles #3304
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
🛠 PR Checks SummaryAll Automated Checks passed. ✅ Manual Checks (for Reviewers):
Read More🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers. ✅ Automated Checks (for Contributors):🟢 Maintainers must be able to edit this pull request (more info) ☑️ Contributor Actions:
☑️ Reviewer Actions:
📚 Resources:Debug
|
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
contribs/nocycles/main.go
Outdated
// find stdlibs | ||
libs := []string{} | ||
gnoRoot := gnoenv.RootDir() | ||
stdlibsDir := filepath.Join(gnoRoot, "gnovm", "stdlibs") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for stdlibs, instead, i think you could change misc/genstd
(note: this binary as well, if it were to stay, would also have to be misc/), by having its import order generator also consider test files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, when I cherry-pick c6728c5 on master, I get:
go run github.com/gnolang/gno/misc/genstd
panic: cyclical package initialization on "bytes" (bytes -> io -> bytes)
I like having code that is dedicated to detecting any cycles in stdlibs and examples though, I'll move the nocycles
code into a test somewhere I think when I get to the polishing step on this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved the test to examples/no_cycles_test.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regarding genstd changes:
actually finding a single global order while including all test files is not possible, consider the following imports (which are allowed in go):
foopkg
/foo_test.go importsbarpkg
barpkg
/bar_test.go importsfoopkg
examining each packages tests deps will yield a different order:
foopkg
tests:barpkg
foopkg
barpkg
tests:foopkg
barpkg
we could fill a map[string][]string
to get the testing order for each lib but I'm not sure this is really helpful, do you want me to add this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this PR not meant to find that order?
The order should exist when excluding the Xtest files, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, it only exists when you include solely the PackageSource
files, the example above is with normal test files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The go stdlib makes it possible to find an order by putting all deps which would lead to circular dependencies in Xtest files. Could we not also do that, and is that not what you did in this PR itself?
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman Meier <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
This makes the imports utils split imports by file kinds, allowing to make explicit decisions about what imports to use at the various callsites - Create `FileKind` enum to categorize gno files, with variants `PackageSource`, `Test`, `XTest` and `Filetest` - Create `GetFileKind` util to derive the `FileKind` from a file name and body - Create `ImportsMap` type that maps `FileKind`s to lists of imports. It has a single method `Merge` to select and merge various imports from multiple `FileKind`s - Modify the`packages.Imports` helper to return an `ImportsMap` instead of a `[]string` and adapt callsites by using`ImportMap.Merge` to preserve existing behavior This is something I need for #3304 and #2932 but to help reviews I made an atomic PR here instead --------- Signed-off-by: Norman Meier <[email protected]> Co-authored-by: Morgan <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
This makes the imports utils split imports by file kinds, allowing to make explicit decisions about what imports to use at the various callsites - Create `FileKind` enum to categorize gno files, with variants `PackageSource`, `Test`, `XTest` and `Filetest` - Create `GetFileKind` util to derive the `FileKind` from a file name and body - Create `ImportsMap` type that maps `FileKind`s to lists of imports. It has a single method `Merge` to select and merge various imports from multiple `FileKind`s - Modify the`packages.Imports` helper to return an `ImportsMap` instead of a `[]string` and adapt callsites by using`ImportMap.Merge` to preserve existing behavior This is something I need for #3304 and #2932 but to help reviews I made an atomic PR here instead --------- Signed-off-by: Norman Meier <[email protected]> Co-authored-by: Morgan <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments on the non-trivial changes, good overall.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this not be a check in gno lint
instead, which is already run on all of examples
?
|
||
import ( | ||
"os" | ||
"path/filepath" | ||
"testing" | ||
|
||
"github.com/gnolang/gno/gnovm/pkg/gnolang" | ||
. "github.com/gnolang/gno/gnovm/pkg/packages" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think this is necessary; we should avoid dot imports unless we have weird cyclical imports in tests like the Go stdlib does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not go in a printtrie_test.gno
file, where it was originally? So it's not exported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make this thread safe, since we want to do gnovm parallel testing?
Depends on #3323
examples/no_cycles_test.go
to detect import cycles in stdlibs and examplesmatchString
native injection in thetesting
stdlib to avoid a cycle inregexp
testsGo never allows import cycles. Our stdlibs have a lot of import cycles, and some examples import self which is not allowed in golang either.
Keeping support for import cycles in stdlib and importing self will require a lot of hacky and weird logic in generic package loading code so I try to tackle this first.
TODO:
check cycles with the test stdlibs overlay applied-> be explicit about the lack of support for modifying imports in testing stdlibs overlay