- 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
```
When updating description cache, if eval_all not set, clear cache rather
than leaving it out of date.
This fixes an issue where, if a user sets `--eval-all` on the command
line to run description searches, but HOMEBREW_EVAL_ALL isn't set in the
environment the cache is never updated.
- Use reference counting so nested `CacheStoreDatabase.use` share the
same underlying database (rather than rereading it every time).
- Only write out the cache database file when it has changed.
- Cleanup cache database entries on formula or full `brew cleanup`.
Fixes#8690
This makes use of both the existing interfaces and could use the
existing cache file but we'll create a new one and cleanup the old one
to avoid issues and use a more consistent name.
After all our recent troubles with DBM I figured I'd benchmark the
performance of DBM vs. JSON. At read time (what we care more about) the
performance is pretty much identical and JSON is only 1.5x slower at
write time. This seems worth it for the reliability increases to avoid
messing with unreliable native code.
When the DBM database cannot be read by the current version of Ruby's
DBM library (due to corruption or another incompatibility) it segfaults
or freezes which takes down the entire Homebrew Ruby process.
This isn't desirable so instead perform a shell out with the Homebrew
Ruby to see if it can read the DBM database before we try to use the
information. If this hangs or crashes: silently delete the database and
recreate it.
