Upgrade x/tools

Upgrades x-tools to fix go 1.23, drops support for go < 1.18

v1.6.0

What's Changed

• Don't check names in declarations by @ashanbrown in #40

Full Changelog: v1.5.4...v1.6.0

v1.5.4

What's Changed

• Fix option to enable type analysis by @ashanbrown in #38

Full Changelog: v1.5.3...v1.5.4

Slight change to handling of missing type information

Refactor package name extraction slightly (#36)

Rename one method and handle case where some type information is missing slightly better.

Ensure that types within a selector are matched

Ensure we match types within a selector (#35)

Also refactor expansion code slightly

Remove deprecated pkg/errors package

Remove deprecated pkg errors (#28)

Replace github.com/pkg/errors with native error handling

pkg/errors has been deprecated since go1.13.
Let's also set go1.13 as the new minimum.

---------

Co-authored-by: Oleksandr Redko <oleksandr.red+github@gmail.com>

Require a configuration option to expand type info

Require an option to be set on analyzer to expand type info (#27)

Because type expansion is a bit experimental and to avoid letting the presence of TypesInfo in the config control the analyzer behavior, let's require a new option to enable analyzing types.

Match patterns against canonical object name instead of source text

This release adds a new matching engine based that matches rules on the canonical name of a package attribute or function instead of raw text as it appears in the source code. It also adds support for a mode where a rule is matched based on the canonical name of a type or interface (see the current README for details). This latter mode requires loading type information from dependencies, which could slow down analysis for things like pre-commit hooks, so it is currently disabled by default. Thanks to @pohly for proposing this change, and for the months he put in to implement it in a way that we hope will cause minimal disruption to existing rules. There are some cases where this may new matching engine may break existing behavior, but we believe the number of such cases will be minimal and have chosen not to consider this a major version release. The release also allows scoping a rule to match from a particular package using a regex.

v1.3.0: Support custom forbid reason messages (#11)

In order to allow users to communicate intent to collaborators,
optionally embed custom messages into each forbidden pattern.

The syntax is as follows: `identifier(# message goes here)?`

Example: `^fmt\.Errorf(# Please don't use this!)?$`

Regular expressions containing custom messages are effectively identical
to ones that don't, because the sub-expression containing it is marked
optional with a `?`. All this commit does is parse out any recognized
custom message, and place it prominently in the tool's output. The
regular expression itself is omitted from the tool's output when a
custom message is specified.

Ignore print/println by default. Standardize //permit directives.

v1.2.0

Add print and println to default exclusions list (#7)