Different results when removing the GOCACHE and pkgs directories
- 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
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