Closed Catya3 closed 2 months ago
~Should be @/testpkg
(probably not documented yet, unfortunately).
The syntax for import is <module>/<path/to/package>
, but for std
module could be omitted. Compiler is aware of stdlib and replaces import {time}
with import {std/time}
.
So when you import testpkg
it should try to find it into stdlib.
However, error doesn't seem to be good. But with our limited resources we need to focus on happy-path now. Issue could remain with "major" status (instead of "critical" otherwise).
@Catya3 please try to replace your import statement with import { @/testpkg }
and try again. Tell me if it didn't help.~
BTW the @
is the name of the user's module. Other module's names are in neva.yaml
(deps section, if you have any). Import path starts from the module's root, where neva.y(a)ml is located.
testpkg was in stdlib in this case
Yes you right, my fault
After debugging with @Catya3 turns out that problem arise when we use some custom type that is defined outside of std:/builtin
(probably because Scope
knows how to resolve builtin
references as a special case), moving Image
to builtin
solved the issue
When we call getNodeOutportType
with nodesIfaces map[string]src.Interface
we ignore the fact that each node interface was found in specific location. We ignore it by passing scope
with the "old" location (where network connection was found).
Pass Location
with every node interface and use it.
Will be fixed in #573
Fixed in #581
please merge main to your branch
I found another occurrence of this in https://github.com/nevalang/neva/tree/repro-struct-builder See https://github.com/nevalang/neva/compare/main...repro-struct-builder
In the feature-std-image branch such struct builder code returns an error like this. It seems to be caused by the use of nested type parameters like Struct<stream
> as simply Struct is not enough to trigger it. This is a minimal repro. It could have something to do with issue https://github.com/nevalang/neva/issues/566 or be subtly different. We might need the same treatment for generic frames.
@Catya3 please merge/rebase fresh main
and check again and close this one if we're cool :)
Thank you BTW
reopen if needed
Describe the bug A issue with the build/analyzer causes types in Component IO not to be fully qualified. The error is as specified in the title. It comes up when you use an external component that exports one of its types in component IO.
The stack looks like this (when the type is used as an outport):
The ultimate error comes from the analyzer.
To Reproduce Steps to reproduce the behavior:
std/testpkg/test.neva
internal/runtime/funcs/test_component.go:
examples/testpkg/main.neva:
Expected behavior We seemingly cannot export types in Component IO. The fix should be somewhere in the builder/analyzer.