chavacava

@silverwind thanks for joining to the discussion could you provide more details about the use of `_` in structs? > Prefixing with _ is common for fields in structs when...

Hi @ChenhuaYang, thanks for filling the issue. As you describe, the rule needs type checking information to complete its analysis. If the type check fails then the rule is unable...

Trying to handle all cases by matching strings will necessarily be an incomplete and uncomfortable solution. For example, using string matching to ignore the following call ```go var b1 strings.Builder...

For the sake of rule simplicity, I think these corner cases should be handled by disabling the linter in the concerned lines. Anyway, I've pushed PR #415 with a fix...

branch https://github.com/mgechev/revive/tree/fix-386 implements a fix consisting in trying to identify channel draining loops by their syntax (a range without value nor key) and avoids raising a failure for such cases...

`revive` relies on the GO parser https://github.com/mgechev/revive/blob/2c895fb33f8f3bb0008ab96dcd8619b2ec79927d/lint/file.go#L33

Type information of each package is calculated lazily. The calculation relies on the GO's `type` package (`go/types.Config.Check`) My understanding of @git-hulk proposition: to make the type calculation _greedy_ (instead of...

> This issue should can be fixed after #716 since it'll load all packages. Yes. The packages management will change completely and it is possible #716 is no longer an...

Yes, type info allows to implement some fancy checks but nothing is free... type info calculation takes time. The idea (as is the case in the current version of `revive`)...

Hi @Groxx, thanks for filling the issue (and sorry for the late response) Il will study the problem this weekend but at a first glance I suspect that the rule...