Unresolved reference

[emil14]

Tooltitude report this error whule VSCode Go isn't. Also reference is defined - I can ctrl+click it. It compiles.

VSCode 1.77.3 Ubuntu 22.04.2 64bit

[tooltitude-support]

Thanks for the feedback. Could you provide more context on what sqldata is, i.e. where is it declared? What is its type? Does it have generics anywhere?

[emil14]

Sorry I'm not sure when I'm going to work with this code again. I remember that sqldata was an imported package. I Don't think generics were involved

[tooltitude-support]

@emil14 Is this a standard package? Or is it something specific to your project?

[tooltitude-support]

@emil14 If you could share the signature of NewContext and WithEndpoint, that would be very helpful.

[romeufcrosa]

Having the same issue with the go-redis pkg

VSCode 1.78.2 macOS Ventura 13.3.1

[tooltitude-support]

@romeufcrosa Thanks a lot! Will take a look!

[tooltitude-support]

@romeufcrosa Thanks! I reproduced it. Will investigate and let you know. It shouldn't be hard to fix.

[tooltitude-support]

@romeufcrosa Does it persist when you reload vscode? For me it got fixed after that.

[tooltitude-support]

@romeufcrosa We fixed the issue where unresolved reference is shown when the library was just added as a dependency. The change should be available in v0.20.0 which we plan to release on Friday.

[romeufcrosa]

@romeufcrosa Does it persist when you reload vscode? For me it got fixed after that.

Yeah, reloading seems to do the trick, hadn't thought to try that. Thanks for the tip, and for the quick fix

[emil14]

Reloading didn't help in my case. Looks like it helps sometimes and sometimes not

[tooltitude-support]

@emil14 Is it your package is it available somewhere in oss so that I could try it or is it something private?

Also, is it possible for your to run go list -m -mod=readonly --json all and share it with me in edited form so that nothing sensitive is there? (internally we run this exact command to get libraries)

[emil14]

Sorry it's private :(

[brennanjl]

Hi all,

Stumbled upon this thread with the same issue. I am running v0.20.1, which I am assuming includes the fix that was shipped in v0.20.0.

Restarting did not fix the issue, however renaming did. Previously, I was importing a package called "testdata". When I would use this in a test, it would get the error "Unresolved Reference". When I changed the package name from "testdata" to just "data", it worked fine.

Hope this helps with diagnosing / reproducibility, big fan of tooltitude!

[tooltitude-support]

@brennanjl Thank you for the info. Is your package located in the testdata directory? If so we ignore it, per some of golang docs. It seems that we shouldn't. However, this is completely different from what other folks are having. Will take a look at how hard it is to fix it, and give you update.

[tooltitude-support]

@brennanjl Checked it out. Go tool spec says the following: Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata". here: https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns

Does it work normally in the gopls (I assume it is)? Other go tools?

[tooltitude-support]

@brennanjl Interestingly, it seems that gopls doesn't support it. I get "(missing metadata for import of" errors, and I could even run the file via go run.

[brennanjl]

@tooltitude-support so the test that was importing it was not in the testdata folder. Here was my directory structure with the package names:

• pkg/engine/datasets (package name: datasets_test)
• pkg/engine/dto/testdata (package name: testdata)

I just tried again, and I also tried importing it into a non-test package:

• pkg/engine/datasets (package name: datasets)

In this most recent test, the package name was still "data"; the only thing that changed was that the import path was "pkg/engine/dto/testdata". As soon as I changed the import path back to "pkg/engine/dto/data", it worked fine.

So in my case, it seems that the differentiating factor causing this is whether the import path has the word "test" in it.

[tooltitude-support]

@brennanjl As I see it, the problem is not the package name, but the name of the folder where the package is located. I.e. you could put a package in the data folder and still name it as testdata and everything should be fine. Could you confirm that this is the case?

I will think how to fix it without breaking testdata convention, and introducing related errors (e.g. go files for tool testing which shouldn't be covered by the tooltitude as part of the project).

[tooltitude-support]

@brennanjl Also, could you please check whether gopls works fine if you use testdata in the path? For me it didn't work at all.

[brennanjl]

@tooltitude-support

Gopls seems to work fine; that is, it reads in testdata normally / without any issue.

I also tried renaming the package to testdata while keeping the filepath as "pkg/engine/dto/data", and that worked fine as well.

So it seems that this issue only occurs when "testdata" is in the import path, and it works fine if it is only in the package name.

[tooltitude-support]

@brennanjl Ok. Thanks a lot for your help!

[tooltitude-support]

@brennanjl We don't ignore testdata and vendor directories in most cases any longer (we ignore vendor dir only if we are pretty sure that it's really a vendor dir). I checked it on a number of OSS project, and everything is working fine. So, in the next version, you could name the package testdata, and not have any problems. Again, thanks you for your feedback, really appreciate it.

P.S. The fix will be available in 0.21.0 which is planned on this Fri.

[brennanjl]

@tooltitude-support awesome, thanks for fixing that! Looking forward to the next release.

Happy to help, tooltitude has been massively helpful for me; the reference counter and auto-implement features are two of the most valuable Goland features, so it's nice to have them in VSCode!

[tooltitude-support]

Found and fixed an additional case of unresolved reference (hope it's the last one). Fix will be available in 0.23.0 this Friday.

[tooltitude-support]

@emil14 Could you try taking a look at the state of broken references now? In 0.25.0 we fixed a serious misunderstanding of how abc_test packages really work.

[vamshiaruru32]

Hello, everyone I am facing this issue too. None of my types are in test folders at all. I am running the latest version of the extension. Here's the minimal reproduction

package main

import (
    "fmt"

    "golang.org/x/exp/maps"
)

type Inner struct {
    Field string
}

type Outer struct {
    Values []Inner
}

func main() {
    testMap := map[string]Outer{}
    vals := maps.Values(testMap)
    for _, v := range vals {
        fmt.Println(v.Values)
    }
}

I am on go 1.21rc3, looks like it fails when using maps.Values

[tooltitude-support]

@vamshiaruru32 Thanks a lot! Reproduced it. Will investigate it today and depending on the severity of the root cause either make a hotfix (i.e. 0.27.5), or release it in 0.28 on Friday.

[tooltitude-support]

@vamshiaruru32 It's a pretty complicated issue. We will try to do our best to fix in 0.28, but it might require more time.

[tooltitude-support]

@vamshiaruru32 Your particular case is fixed and will be available in 0.28, this Friday, there're some similar issues though, which will take more time to fix.

[vamshiaruru32]

Thank you @tooltitude-support , you guys are awesome :D

[tooltitude-support]

@vamshiaruru32 The build is out. Please update to 0.28.2, 0.28.0 doesn't work well on desktop version of vscode (i.e. non remote)

[tooltitude-support]

It has been a long time since the issue was reported. There were several fixes for different causes of this issue since then. I am closing it, since these were different bugs. If you have this error again, please create a new issue. We will deal with them separately.