- 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
```
- Found with
`grep -rL "# typed: strict" Library/Homebrew | xargs grep -l "undef "`.
- This stops people from trying to bump them and
getting an error that they can't fix because
[it's a Sorbet limitation](https://sorbet.org/docs/error-reference#3008),
wasting contributor time.
- check the version of `/usr/bin/ld` for support of `-no_fixup_chains`
- check for usage of the `-fuse-ld` flag, since this flag is only
supported by Apple ld64
Also, call `no_fixup_chains` when setting up the build environment.
Invoking `ld` with `-undefined dynamic_lookup` emits a warning starting
Xcode 14:
ld: warning: -undefined dynamic_lookup may not work with chained fixups
Chained fixups is a linker optimisation that results in faster binary
load times, and is enabled by default starting Xcode 13 when the target
is macOS 12 or newer.
However, this interacts poorly with `-undefined dynamic_lookup`, and
Xcode will disable chained fixups when it is invoked with this flag
starting Xcode 14.3. Until then, we may be shipping binaries that are
broken in subtle ways, so let's disable chained fixups when necessary
instead.
I patterned the changes here after the handling of `-no_weak_imports`.
The only difference is that we need to check the flags that were passed
to the linker first to see if we do need to disable chained fixups.
For additional context, see:
https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-noteshttps://www.wwdcnotes.com/notes/wwdc22/110362/https://www.emergetools.com/blog/posts/iOS15LaunchTimehttps://github.com/python/cpython/issues/97524https://github.com/pybind/pybind11/pull/4301
One of the more curious bugs, if you use
-Wl,-headerpad_max_install_names on linux, it tries to link a library
named "eaderpath_max_install_names" in, which causes all kinds of weird
havoc.
Most notably, gtester inside glib fails to run for bizarre reasons.
-Wl,-headerpad_max_install_names is not an option anywhere outside macos
anyway, so move it to macos only and avoid the heartache of extremely
weild bugs.
This probably has to wait until 2.7.0 now and will require a bunch of
formula changes/deprecations but we should probably start moving in this
direction given we're not installing any of these on our CI any more.
