should I check the array for not nilness? as far as I understood, in this case (where its receiver) there are always should be some fields, but the safer the better?

you can add a simple func in golden files if it fails - better to add :)

It does not fail, because it goes after decl.Recv != nil where Recv is recivier

if the project already has similar function plz, point my nose

I'm not 100% sure that we need this func yet 👀

so, what should we do?

AFAIK, the receiver name node is either *ast.Ident or *ast.StarExpr. So instead of doing an AST->string->trimAsterisk you can do:

func (c *typeDefFirstChecker) receiverType(e ast.Expr) string {
  switch e := e.(type) {
  case *ast.Pointer:
    return c.receiverType(e.X)
  case *ast.Ident:
    return e.Name
  default:
    panic("unreachable")
  }
}

The trimAsterisk function, if we even wanted it, should be a method of the checker type. All helpers that are not generally useful should be encapsulated as a checker detail. As a general rule: no top-level functions should be defined inside the checker file.

Wow, I am not familiar with all type relations, maybe some map or guide exists? That makes trimAsterisk
unnecessary

I think the closest thing is Go spec.
Although it's not always the most precise source as it defines valid receiver in its grammar as a normal param, but you can't have a slice type for a receiver, for example.

File-scoped checker I'm curious - should be use this phrase in other checkers? maybe another tag or subtype? @quasilyte :)

you can add a simple func in golden files if it fails - better to add :)

move it after "github.com/go-critic/go-critic/framework/linter" please

I'm not 100% sure that we need this func yet 👀

You can decrease the nesting even further:

for _, spec := range decl.Specs {
	spec, ok := spec.(*ast.TypeSpec)
	if !ok {
		continue
	}

This idiom is quite common.

I know, but continue in nested for it is a little harder to understand, that is why I asked

You know the solution to that: don't nest a lot of fors. :)
It's always possible to define another method and call that, so you don't have too much control flow on the same level.
But I'm OK with the current level of nesting. AST requires a lot of things like this, unfortunately (GenDecl is the most horrible one, the next one is assignment-related stuff).