feat: add explicitreturn linter

[maxsond]

Source: https://tildegit.org/indigo/explicitreturn

This adds a linter that requires functions to have explicit return statements. It's broadly similar to nakedret, but with a slightly different philosophy.

For one thing, the size of the code doesn't matter. This will catch inline functions which I missed when I used nakedret (e.g. var x in my test).

As well, I would not consider alexkohler/nakedret#18 to be a bug because the function in that issue returns an error and a nil error is still a nil value so I would want to see that stated explicitly. The author of nakedret doesn't seem to take that view which is fine, but was part of what pushed me to writing this separately rather than working directly on nakedret as well as a PR that's been open for review on that project for quite a while now.

[boring-cyborg]

Hey, thank you for opening your first Pull Request !

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ldez]

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description about the linter.

Linter

• It must not be a duplicate of another linter or a rule of a linter. (the team will help to verify that)
• It must have a valid license and the file must contain the required information by the license, ex: author, year, etc.
• The linter repository must have a CI and tests.
• It must use go/analysis.
• It must have a valid tag, ex: v1.0.0, v0.1.0.
• It must not contain init().
• It must not contain panic(), log.fatal(), os.exit(), or similar.
• It must not have false positives/negatives. (the team will help to verify that)
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must work with T=<name of the linter test file>.go make test_linters. (the team will help to verify that)

.golangci.reference.yml

• The linter must be added to the list of available linters (alphabetical case-insensitive order).
  • enable and disable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Others Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The .golangci.yml of golangci-lint itself must not be edited and the linter must not be added to this file.
• The linters must be sorted in the alphabetical order (case-insensitive) in the Manager.GetAllSupportedLinterConfigs(...) and .golangci.reference.yml.
• The load mode (WithLoadMode(...)):
  • if the linter doesn't use types: goanalysis.LoadModeSyntax
  • goanalysis.LoadModeTypesInfo required WithLoadForGoAnalysis() in the Manager.GetAllSupportedLinterConfigs(...)
• The version in WithSince(...) must be the next minor version (v1.X.0) of golangci-lint.

Recommendations

• The linter should not use SSA. (currently, SSA does not support generics)
• The linter repository should have a readme and linting.
• The linter should be published as a binary. (useful to diagnose bug origins)

---

The golangci-lint team will edit this comment to check the boxes before and during the review.

This checklist does not imply that we will accept the linter.

[maratori]

@maxsond Why the linter doesn't report about the first return?

func MultipleReturnPaths() (x int, y string) {
	if true {
		return // ok ?
	}
	return // want `implicit return found in function MultipleReturnPaths`
}

[maxsond]

Why the linter doesn't report about the first return?

This is a bug. The current implementation only looks at statements directly inside the function statement, not at statements inside other statements (in this case an if statement). Will fix this. Thanks for catching it.

[ldez]

Feel like a duplicate of nonamedreturns 🤔

[maxsond]

It was born out of nonamedreturns and I worked mainly from nonamedreturns when making it. My team was originally discussing that one, but we agreed that we did want named returns (we find them nice for documenting what the result is beyond just the type) so nonamedreturns was not what we were looking for, but we did not want named returns to then permit naked/implicit return statements because that's a confusing convention for programmers from most other languages (in our collective opinion, at least, and there's some lively discussion on this in the context of Go2 as well here: golang/go#21291).

That's why I say it's closest to nakedret which we may actually use instead of this because the differences between the two which I noted above are minor enough they shouldn't impact us.

[ldez]

@maxsond you have to sign the CLA.

[rittneje]

@maxsond Please note that alexkohler/nakedret#18 has now been closed as "as designed". (It was just some confusion due to a misunderstanding.)

[maxsond]

Ah, cool. Then I think this linter is redundant. I'll go ahead and close it.