x/tools/gopls: inconsistent build tag handling creates false import errors

[yevhen-onykiienko-snkeos]

Summary

The VS Code Go extension has inconsistent behavior when handling build tags: it parses files (currently opened file) with build tags that don't match the current go.buildTags setting, but treats imports to other files with the same build tags as unresolvable, creating false import errors.

Problem Description

When working with files that have build tags (e.g., //go:build test), VS Code exhibits inconsistent behavior:

1. Files with unmatched build tags are still parsed - VS Code shows syntax highlighting, IntelliSense, etc.
2. But imports to other files with the same build tags show as errors - even when those files would be part of the same compilation unit

This creates a confusing situation where VS Code complains about "missing" imports that would resolve perfectly fine during actual compilation.

Steps to Reproduce

1. Create a file with a build tag that imports another file with the same build tag:

   //go:build test
   package testdata
   
   import (
       "github.com/myproject/internal/test-utils/generate" // Shows error
   )

2. Ensure both files have the same build tag //go:build test

3. Set VS Code go.buildTags to NOT include test (or leave it empty)

4. Open the importing file in VS Code

Expected Behavior

VS Code should either:

1. Include all files with matching build tags when analyzing any file with those tags, OR
2. Completely ignore files whose build tags don't match the current settings

Actual Behavior

VS Code:

• Parses and shows the importing file (with syntax highlighting, etc.)
• Shows import errors for files with the same build tag
• Creates false "unresolved import" errors even though both files have identical build tags

Why This Is Problematic

1. Build tags define compilation units - files with the same build tag are compiled together
2. The current behavior violates this principle by treating files in the same compilation unit inconsistently
3. Creates false import errors for imports that are perfectly valid in the actual compilation context

Real-World Example

//go:build test
package testdata

import (
    "github.com/myproject/internal/test-utils/generate"
    "github.com/stretchr/testify/require"
)

func Generate(t *testing.T, size int64) *Data {
    data, err := generate.RandomBytes(size)  // generate.RandomBytes shows as unresolved
    require.NoError(t, err, "setup: gen test data")
    // ... rest of function
}

Even though both testdata.go and generate.go have the same //go:build test tag, VS Code shows the import as unresolvable unless test is added to the global go.buildTags setting.

Environment

• VS Code version: 1.105.1
• Go extension version: 0.50.0
• Go version: 1.25
• OS: Windows

Compilation Verification

The code compiles perfectly fine when using the correct build tags:

go build -tags=test ./internal/test-utils/testdata/
# ✅ No errors - both files are included in the same compilation unit

Proposed Solution

The Go extension should respect that build tags define compilation boundaries and either:

1. Smart tag resolution per file: When analyzing a file with build tags, automatically include all other files with matching tags in the analysis context
2. Complete exclusion: Completely ignore files whose build tags don't match, rather than this hybrid approach of parsing but not resolving dependencies
3. Configuration option: Provide a setting to enable context-aware build tag resolution

The current behavior of partial inclusion is logically inconsistent with how Go's build system actually works.

Impact

This issue affects any Go project that uses build tags for:

• Test utilities (common pattern: //go:build test)
• Platform-specific code
• Feature flags
• Integration tests

Users are forced to either:

• Add all build tags to global settings (defeating the purpose of tags)
• Live with constant false import errors
• Avoid using build tags altogether