Resolution fails for go files inline with proto files

[ramilmsh]

Description of the bug:

Failure case: https://github.com/ramilmsh/golangtest

When using proto generated files along with inline go files to extend functionality of the generated structures, symbol resolution fails

As far as I understand, the issue is that this file is never picked up https://github.com/ramilmsh/golangtest/blob/46ccea35e2b6cdaf2bea658ebcbc34167b1fbfb7/libs/b/b.go#L5

And so the function is never analyzed.

Same logic works in vscode, since gopackagesdriver finds it alright:

{
    "ID": "@//libs/b:b",
    "Name": "b",
    "PkgPath": "github.com/ramilmsh/golangtest/libs/b",
    "GoFiles": [
        "/private/var/tmp/_bazel_r/4c665bb08173cfcca16456a97f0f7de3/execroot/__main__/bazel-out/darwin_arm64-fastbuild/bin/libs/b/libs_b_go_proto_/github.com/ramilmsh/golangtest/libs/b/b.pb.go",
        "<path>/golangtest/libs/b/b.go"
    ],
    "CompiledGoFiles": [
        "/private/var/tmp/_bazel_r/4c665bb08173cfcca16456a97f0f7de3/execroot/__main__/bazel-out/darwin_arm64-fastbuild/bin/libs/b/libs_b_go_proto_/github.com/ramilmsh/golangtest/libs/b/b.pb.go",
        "<path>/golangtest/libs/b/b.go"
    ],
    "ExportFile": "/private/var/tmp/_bazel_r/4c665bb08173cfcca16456a97f0f7de3/execroot/__main__/bazel-out/darwin_arm64-fastbuild/bin/libs/b/b.x",
    "Imports": {
        "github.com/golang/protobuf/proto": "@com_github_golang_protobuf//proto:proto",
        "github.com/ramilmsh/golangtest/libs/a": "@//libs/a:a",
        "google.golang.org/protobuf/proto": "@org_golang_google_protobuf//proto:proto",
        "google.golang.org/protobuf/reflect/protoreflect": "@org_golang_google_protobuf//reflect/protoreflect:protoreflect",
        "google.golang.org/protobuf/runtime/protoiface": "@org_golang_google_protobuf//runtime/protoiface:protoiface",
        "google.golang.org/protobuf/runtime/protoimpl": "@org_golang_google_protobuf//runtime/protoimpl:protoimpl",
        "google.golang.org/protobuf/types/descriptorpb": "@org_golang_google_protobuf//types/descriptorpb:descriptorpb",
        "google.golang.org/protobuf/types/known/anypb": "@org_golang_google_protobuf//types/known/anypb:anypb",
        "google.golang.org/protobuf/types/known/apipb": "@org_golang_google_protobuf//types/known/apipb:apipb",
        "google.golang.org/protobuf/types/known/durationpb": "@org_golang_google_protobuf//types/known/durationpb:durationpb",
        "google.golang.org/protobuf/types/known/emptypb": "@org_golang_google_protobuf//types/known/emptypb:emptypb",
        "google.golang.org/protobuf/types/known/fieldmaskpb": "@org_golang_google_protobuf//types/known/fieldmaskpb:fieldmaskpb",
        "google.golang.org/protobuf/types/known/sourcecontextpb": "@org_golang_google_protobuf//types/known/sourcecontextpb:sourcecontextpb",
        "google.golang.org/protobuf/types/known/structpb": "@org_golang_google_protobuf//types/known/structpb:structpb",
        "google.golang.org/protobuf/types/known/timestamppb": "@org_golang_google_protobuf//types/known/timestamppb:timestamppb",
        "google.golang.org/protobuf/types/known/typepb": "@org_golang_google_protobuf//types/known/typepb:typepb",
        "google.golang.org/protobuf/types/known/wrapperspb": "@org_golang_google_protobuf//types/known/wrapperspb:wrapperspb",
        "google.golang.org/protobuf/types/pluginpb": "@org_golang_google_protobuf//types/pluginpb:pluginpb",
        "reflect": "@io_bazel_rules_go//stdlib:reflect",
        "sync": "@io_bazel_rules_go//stdlib:sync"
    }
}

And bazel builds it without errors:

$ bazel run //service1:service1
INFO: Analyzed target //service1:service1 (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //service1:service1 up-to-date:
  bazel-bin/service1/service1_/service1
INFO: Elapsed time: 0.133s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
INFO: Running command line: bazel-bin/service1/service1_/service1
a:"b"

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Minimal example can be found here: https://github.com/ramilmsh/golangtest

Which Intellij IDE are you using? Please provide the specific version.

GoLand 2023.2 Build #GO-232.8660.185

What programming languages and tools are you using? Please provide specific versions.

go

What Bazel plugin version are you using?

2023.07.21.0.1-api-version-232

Have you found anything relevant by searching the web?

not really

Any other information, logs, or outputs that you want to share?

GoLand 2023.2
Build #GO-232.8660.185, built on July 26, 2023
Licensed to Ramil Shaymardanov
Subscription is active until April 25, 2024.
Runtime version: 17.0.7+7-b1000.6 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.0
GC: G1 Young Generation, G1 Old Generation
Memory: 8192M
Cores: 10
Metal Rendering is ON
Registry:
    suggest.all.run.configurations.from.context=true
    debugger.new.tool.window.layout=true
    ide.completion.variant.limit=500
    ide.experimental.ui=true

Non-Bundled Plugins:
    com.jetbrains.plugins.ini4idea (232.8660.205)
    com.github.lppedd.idea-conventional-commit (0.22.0)
    com.markskelton.one-dark-theme (5.8.0)
    com.github.copilot (1.2.21.2995)
    String Manipulation (9.10.0)
    com.crunch42.openapi (1.66)
    org.toml.lang (232.8660.88)
    com.intellij.kubernetes (232.8660.158)
    PythonCore (232.8660.185)
    com.koxudaxi.pydantic (0.4.7)
    com.github.blarc.gitlab-template-lint-plugin (1.13.2)
    izhangzhihao.rainbow.brackets (2023.3.2)
    com.intellij.bigdatatools.core (232.8660.206)
    com.intellij.bigdatatools.binary.files (232.8660.206)
    com.intellij.bigdatatools.rfs (232.8660.206)
    com.google.idea.bazel.ijwb (2023.07.21.0.1-api-version-232)
    net.ashald.envfile (3.4.1)
    io.kanro.idea.plugin.protobuf (1.7.14)

[blorente]

I've tried to repro the issue you mention on a branch on top of #5567 (branch), and I haven't been able to. The symbol embedded.Message in here seems to resolve fine with the changes in that PR.

However, I'd be willing to bet that you're not meant to embed a go_proto_library into another go_proto_library, and instead the pattern is to crate go_libraryes for each go_proto_library, and then embed/depend on those. At least, that's how Gazelle does it (note that I had to turn off gazelle for the reproduction to happen at all, it wouldn't let me write those BUILD files otherwise).

I'd be happy to look into this further if you could provide a repro (on top of my branch if it would be useful).

[ramilmsh]

@blorente

I've pulled from your branch and then did a non-incremental sync on BUILD files and it appears to work great. No idea why didn't work before and works now, maybe i didn't properly reset the analysis cache somehow, I assume(?)

I haven't checked every single issue I had manually, but analysis shows no import errors, so I think it's ok now

Looking forward to have Goland be usable again, once this fix is released. Thanks!