- Previously I thought that comments were fine to discourage people from
wasting their time trying to bump things that used `undef` that Sorbet
didn't support. But RuboCop is better at this since it'll complain if
the comments are unnecessary.
- Suggested in https://github.com/Homebrew/brew/pull/18018#issuecomment-2283369501.
- I've gone for a mixture of `rubocop:disable` for the files that can't
be `typed: strict` (use of undef, required before everything else, etc)
and `rubocop:todo` for everything else that should be tried to make
strictly typed. There's no functional difference between the two as
`rubocop:todo` is `rubocop:disable` with a different name.
- And I entirely disabled the cop for the docs/ directory since
`typed: strict` isn't going to gain us anything for some Markdown
linting config files.
- This means that now it's easier to track what needs to be done rather
than relying on checklists of files in our big Sorbet issue:
```shell
$ git grep 'typed: true # rubocop:todo Sorbet/StrictSigil' | wc -l
268
```
- And this is confirmed working for new files:
```shell
$ git status
On branch use-rubocop-for-sorbet-strict-sigils
Untracked files:
(use "git add <file>..." to include in what will be committed)
Library/Homebrew/bad.rb
Library/Homebrew/good.rb
nothing added to commit but untracked files present (use "git add" to track)
$ brew style
Offenses:
bad.rb:1:1: C: Sorbet/StrictSigil: Sorbet sigil should be at least strict got true.
^^^^^^^^^^^^^
1340 files inspected, 1 offense detected
```
Currently the codesign_patched_binary method may be called many
times for the same file when installing a keg.
This removes the calls to codesign_patched_binary from os/mac/keg
and adds a single call to the relocate_dynamic_linkage and
fix_dynamic_linkage methods in extend/os/mac/keg_relocate
to speed up keg installation.
This is just a recipe for infinite loops. Plus, recursive references are
likely to be invalid, so we don't really gain much by attempting to
resolve them.[^1] (But we could if we made the logic here much more
complicated.)
Fixes a CI failure seen at Homebrew/homebrew-core#138323.
[^1]: See, for example, embree/embree#455.
We can add a small amount of logic to `#resolve_variable_name` that will
allow us to perform (limited) resolution of rpath references. This is
for informational purposes only: failing to resolve an `@rpath`
reference will not (and should not) result in `brew linkage` failures.
`dyld` will typically have more information than we do to resolve these
references, so not failing `brew linkage` when we fail to resolve an
`@rpath` reference is the right behaviour here.
As an example, before:
❯ brew linkage jpeg-turbo
System libraries:
/usr/lib/libSystem.B.dylib
@rpath-referenced libraries:
@rpath/libjpeg.8.dylib
@rpath/libturbojpeg.0.dylib
After:
❯ brew linkage jpeg-turbo
System libraries:
/usr/lib/libSystem.B.dylib
Homebrew libraries:
/usr/local/Cellar/jpeg-turbo/3.0.0/lib/libjpeg.8.dylib (jpeg-turbo)
/usr/local/Cellar/jpeg-turbo/3.0.0/lib/libturbojpeg.0.dylib (jpeg-turbo)
This implements the TODO that I left as a comment from #15722.
In order to simplify the handling of deleting an absolute rpath that has
a relative duplicate (or vice-versa, i.e., a relative rpath with an
absolute duplicate), we relocate all rpaths first in one pass and then
delete the duplicates in a separate pass.
We currently rely on some lower-level (but still public) methods from
ruby-macho since the standard `#delete_rpath` method changes the order
in which rpaths are resolved. We can switch back to using
`#delete_rpath` when Homebrew/ruby-macho#555 is merged and released.
