mgechev / mgechev/revive

Different results when removing the GOCACHE and pkgs directories

Open
#680 14 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
5.6k
Forks
330
Avg merge
1d 21h
Merged PRs (30d)
9

Description

**Describe the bug**

This is more of a **"i need a better idea on how to debug this"** bug reports because i do have a reproducer, but it involves our monorepo (which i can't just send out).

The bug of this issue is that the output of revive is not deterministic for one specific problem. The following Revive config enables the rule that finds the reported problem.

```toml
[rule.range-val-address]
Disabled = false
```

Which leads to the following problem in the reproducer i am currently reducing:

`tt.go:20:15: suspicious assignment of 'p'. range-loop variables always have the same address`

The problem appears deterministically in our CI but it does not appear locally on my machine right away. I need to do some steps to reproduce it but then it is again deterministically reporting the problem.

```bash
revive --config config.toml tt.go # Does not report a problem.
rm -rf $GOCACHE pkg/
revive --config ok.toml tt.go # Suddenly reports a problem.
go install $our-project/...
revive --config config.toml tt.go # Does not report a problem.
```

First i thought it is a race, but when i compile Revive with the race detector on, there is no race anymore with the latest changes. So i ran out of ideas on what the problem is.

One idea i had was that this must have something to do with how packages are loaded to resolve types because i reduce the code down to:

```go
func prepareTestsForValidation(tests []*model.ProjectTest) {
for _, test := range tests {
for _, p := range test.Result.Problems {
problem := &p.Problem
problem.Message = "abc"
}
}
}
```

"model" is an import identifier. When i copy the types directly into the same file as the reduce code, Revive does not report a problem anymore.

**Expected behavior**

I would expected to always have the same problem.

**Desktop:**
- OS: SUSE LEAP 15.3 locally and Ubuntu 20.04 in the CI which runs in Kubernetes+latest Docker
- Version of Go: 1.18.0

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the reported sequence with revive --config, clearing $GOCACHE and pkg/, and reinstalling the project packages. Focus on the range-val-address rule and the reduced example involving the imported model package. Done means the same diagnostic is produced consistently across clean-cache and rebuilt-package runs, with the loading or analysis cause identified.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.