GitLab

Bumps [rubocop](https://github.com/rubocop/rubocop) from 1.22.0 to 1.23.0.
- [Release notes](https://github.com/rubocop/rubocop/releases)
- [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rubocop/rubocop/compare/v1.22.0...v1.23.0

)

---
updated-dependencies:
- dependency-name: rubocop
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Revert "linkage_checker: check variable references with dlopen"

Trying to `dlopen` some Qt libraries causes Ruby to crash.

This reverts commit 0191a275.

linkage_checker: check variable references with dlopen

Also show issues URL on macOS arm64

spdx: update license data.

Autogenerated by [a scheduled GitHub Action](https://github.com/Homebrew/brew/blob/master/.github/workflows/spdx.yml).

rubocops/text: forbid "go get" only in install method

The linkage check currently does nothing to check the validity of
variable-referenced libraries (prefixed with an `@`).

We could rectify that by mimicking the dynamic linker in looking up the
variable-referenced library, but this could get quite complicated.
Instead, let's let the linker do the hard work by checking if we can
`dlopen` libraries and bundles that contain variable linkage. The
`dlopen` will fail if the linker cannot resolve the variable reference.

There are at least two disadvantages to this approach relative to the
alternative suggested above:
1. This doesn't work for binary executables.
2. This doesn't identify which variable references are broken.

It's still better than not checking them at all, which is what we do
currently, and saves us from having to carry around code that parses and
verifies variable references directly.

Update maintainers, manpage and completions.

build(deps): bump mechanize from 2.8.1 to 2.8.3 in /Library/Homebrew

Autogenerated by the [update-man-completions](https://github.com/Homebrew/brew/blob/HEAD/.github/workflows/update-man-completions.yml) workflow.

Bumps [mechanize](https://github.com/sparklemotion/mechanize) from 2.8.1 to 2.8.3.
- [Release notes](https://github.com/sparklemotion/mechanize/releases)
- [Changelog](https://github.com/sparklemotion/mechanize/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/mechanize/compare/v2.8.1...v2.8.3

)

---
updated-dependencies:
- dependency-name: mechanize
  dependency-type: direct:production
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

utils/shfmt.sh: improve shell formatter usage

list: raise NoSuchKegError if formula exists but isn't installed

bump: skip PR check if livecheck does not return a version

vendor-install: handle native ARM running under Rosetta

This condition is always true when we've reached this branch.

GitHub.create_bump_pr: don't leak GitHub token if set via environment variable

Whenever the `sysctl` call does not match `"Apple"*`, we can be sure
that `HOMEBREW_PROCESSOR` is `Intel`, so there's no need for this
additional check.

The previous commit only prevented the installation of an Intel Portable
Ruby into `/opt/homebrew` prefix. Let's actually install an ARM64
Portable Ruby there too.

Since `HOMEBREW_PROCESSOR` is populated using `uname -m`, this will
register as `Intel` even when a native ARM install is running under
Rosetta.

Let's work around this by checking `sysctl -n machdep.cpu.brand_string`.
On my Intel machine:

    ❯ sysctl -n machdep.cpu.brand_string
    Intel(R) Core(TM) i3-1000NG4 CPU @ 1.10GHz

On Apple Silicon:

    brew@HMBRW-A-001-M1-001 ~ % sysctl -n machdep.cpu.brand_string
    Apple M1

The case of a Rosetta installation of Homebrew is already handled below
the proposed change.

Fixes Homebrew/discussions#2434.

build(deps-dev): bump sorbet from 0.5.9309 to 0.5.9318 in /Library/Homebrew

build(deps): bump unparser from 0.6.1 to 0.6.2 in /Library/Homebrew