nevalang / neva

🌊 Dataflow programming language with static types and implicit parallelism. Compiles to native code and Go
https://nevalang.org
MIT License
87 stars 7 forks source link

can't get type def from scope by ref: entity not found: '$TYPE' #566

Closed Catya3 closed 2 months ago

Catya3 commented 2 months ago

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):

sourcecode.Scope.GetType (/home/$USER/src/github.com/Catya3/neva/internal/compiler/sourcecode/scope.go:58) sourcecode.(*Scope).GetType (Unknown Source:1) typesystem.Resolver.getDef (/home/$USER/src/github.com/Catya3/neva/internal/compiler/sourcecode/typesystem/resolver.go:315) typesystem.Resolver.resolveExpr (/home/$USER/src/github.com/Catya3/neva/internal/compiler/sourcecode/typesystem/resolver.go:232) typesystem.Resolver.ResolveExprWithFrame (/home/$USER/src/github.com/Catya3/neva/internal/compiler/sourcecode/typesystem/resolver.go:64) analyzer.Analyzer.getResolvedPortType (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component_net.go:564) analyzer.Analyzer.getNodeOutportType (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component_net.go:776) analyzer.Analyzer.getSenderPortAddrType (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component_net.go:670) analyzer.Analyzer.getSenderSideType (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component_net.go:608) analyzer.Analyzer.analyzeConnection (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component_net.go:161) analyzer.Analyzer.analyzeConnections (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component_net.go:60) analyzer.Analyzer.analyzeComponentNetwork (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component_net.go:34) analyzer.Analyzer.analyzeComponent (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/component.go:112) analyzer.Analyzer.analyzeEntity (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/analyzer.go:225) analyzer.Analyzer.analyzePkg.func1 (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/analyzer.go:164) sourcecode.Package.Entities (/home/$USER/src/github.com/Catya3/neva/internal/compiler/sourcecode/sourcecode.go:78) analyzer.Analyzer.analyzePkg (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/analyzer.go:157) analyzer.Analyzer.analyzeModule (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/analyzer.go:125) analyzer.Analyzer.AnalyzeBuild (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/analyzer.go:79) analyzer.Analyzer.AnalyzeExecutableBuild (/home/$USER/src/github.com/Catya3/neva/internal/compiler/analyzer/analyzer.go:63)

The ultimate error comes from the analyzer.

To Reproduce Steps to reproduce the behavior:

std/testpkg/test.neva

pub type Foo struct {}

#extern(test_component)
pub component TestComponent(foo any) (foo Foo)

internal/runtime/funcs/test_component.go:

package funcs

import (
    "context"

    "github.com/nevalang/neva/internal/runtime"
)

type testComponent struct{}

func (testComponent) Create(io runtime.FuncIO, _ runtime.Msg) (func(ctx context.Context), error) {
    return func(ctx context.Context) {
        for { // Do nothing...
        }
    }, nil
}

examples/testpkg/main.neva:

import {
  testpkg
}

component Main(start) (stop) {
  nodes {
    testpkg.TestComponent
  }
  net {
    :start -> testComponent -> :stop
  }
}

Expected behavior We seemingly cannot export types in Component IO. The fix should be somewhere in the builder/analyzer.

emil14 commented 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.

Catya3 commented 2 months ago

testpkg was in stdlib in this case

emil14 commented 2 months ago

Yes you right, my fault

emil14 commented 2 months ago

Update

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

Why this is happening

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).

Possible solution

Pass Location with every node interface and use it.

emil14 commented 2 months ago

Will be fixed in #573

emil14 commented 2 months ago

Fixed in #581

please merge main to your branch

Catya3 commented 2 months ago

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.

emil14 commented 2 months ago

@Catya3 please merge/rebase fresh main and check again and close this one if we're cool :)

Thank you BTW

emil14 commented 2 months ago

reopen if needed