This is an easy win for `git add ` completion time if we have multiple descriptions.
What happened was we did things once per description string, but the
things included a bunch of computation (including multiple `string`
calls and even a `realpath`!). Because these don't change, we can
simply do them once.
And it turns out we can just use a cartesian product:
for d in $desc
printf '%s\t%s\n' $file $d
end
becomes
printf '%s\n' $file\t$desc
lazy_static has better ergonomics at the call/access sites (it returns a
reference to the type directly, whereas with once_cell we get a static Lazy<T>
that we must dereference instead) but the once_cell api is slated for
integration into the standard library [0] and has been the "preferred" way to
declare static global variables w/ deferred initialization. It's also less
opaque and easier to comprehend how it works, I guess?
(Both `once_cell` and `lazy_static` are already in our dependency tree, so this
should have no detrimental effect on build times. It actually negligibly
*improves* build times by not using macros, reducing the amount of expansion the
compiler has to do by a miniscule amount.)
[0]: https://github.com/rust-lang/rust/issues/74465
I have no idea why `apt-cache --no-generate show` is so slow since it basically
dumps the contents of the cache file located at `/var/lib/dpkg/status`. We are
technically bypassing any waits on the cache lock file so this may produce
incorrect results if the cache is being regenerated in the moment, but that's a
small price to pay and the results are likely confined to simply not generating
comprehensive results.
With this change, we no longer need to truncate results to the first n matches
and we no longer only print packages beginning with the commandline argument
enabling fish's partial completions logic to offer less-perfect suggestions when
no better options are available.
Even though we are generating more usable completions, we still trounce the old
performance by leaps and bounds:
```
Benchmark #1: fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 2.165 s ± 0.033 s [User: 267.0 ms, System: 1932.2 ms]
Range (min … max): 2.136 s … 2.256 s 10 runs
Benchmark #2: build/fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 111.1 ms ± 1.8 ms [User: 38.9 ms, System: 72.9 ms]
Range (min … max): 108.2 ms … 114.9 ms 26 runs
Summary
'build/fish -c "complete -C\"apt install ac\""' ran
19.49 ± 0.44 times faster than 'fish -c "complete -C\"apt install ac\""'
```
I think this should be preferred for all subcommand completions because it
handles typos or subcommands we don't recognize better (`apt foo <TAB>` no
longer suggests subcommands since the subcommand position has been taken).
It's debatable whether is_ascii_digit() is better than (0..=9).contains().
(Probably we want to go with the mainstream Rust choice eventually.)
Let's disable the warning for now since it's not terribly important.
We should only be dealing with wcharz_t at the language boundary.
Rust callers should prefer the equivalent &wstr.
Since wcsfilecmp() is no longer exposed directly it can take &wstr only.
- Added phx completions. These are very common completions for the Elixir Phoenix Framework.
Documentation can be found here: https://hexdocs.pm/phoenix/1.7.0-rc.2/Mix.Tasks.Local.Phx.html#content
- Added argument completions
- Made all descriptions start with an uppercase for better consistency
- Update CHANGELOG.rst
This is early work but I guess there's no harm in pushing it?
Some thoughts on the conventions:
Types that live only inside Rust follow Rust naming convention
("FeatureMetadata").
Types that live on both sides of the language boundary follow the existing
naming ("feature_flag_t").
The alternative is to define a type alias ("using feature_flag_t =
rust::FeatureFlag") but that doesn't seem to be supported in "[cxx::bridge]"
blocks. We could put it in a header ("future_feature_flags.h").
"feature_metadata_t" is a variant of "FeatureMetadata" that can cross
the language boundary. This has the advantage that we can avoid tainting
"FeatureMetadata" with "CxxString" and such. This is an experimental approach,
probably not what we should do in general.
The initial port of feature flags requires a global initialization. Since
fish_indent accesses feature flags, let's make sure to initialize them here.
In future, we can stop initializing things fish_indent doesn't need (like
the topic monitor) but that's no big deal. Global initialization should
always be a benign addition.
The original implementation without the test took me 3 hours (first time
seriously looking into this)
The functions take "wcharz_t" for smooth integration with existing C++ callers.
This is at the expense of Rust callers, which would prefer "&wstr". Would be
nice to declare a function parameter that accepts both but I don't think
that really works since "wcharz_t" drops the lifetime annotation.
rustfmt removes the "::" prefix from qualifiers. This breaks the build because
I think a later "pub use ffi::*" results in "std" being an ambiguous reference.
We can re-enable these once we're nearing a RIIR release (or if someone thinks
it's a good use of their time to fix them before then). Otherwise we're just
going to have GitHub reporting CI failure for all commits instead of just the
ones that actually broke something.
(I'm mainly trying to get the branch in a good state to merge into master.)
Use rustup to install the latest version of rust. The latest version of rust
available from pkg is 1.66.0 while the code currently needs 1.67.0 or later.
The nix crate had all its default features enabled, which included features that
are not present under BSD. We should only enable the select subset of crate
features that we know are available cross-platform (or else use conditional
targeting in Cargo.toml to only enable Linux-only features when compiling for
Linux targets).
For now, it seems we can just use the nix crate with all features disabled as it
still builds under Linux and FreeBSD in this state.
The `cmake` meta package pulls in `cmake-core`, `cmake-docs`, and `cmake-man` -
we don't need the latter two.
(It seems to be available on all the versions/architectures we target.)
The git-lite flavor, being significantly smaller and downloading/installing much
faster with fewer dependencies, is much better suited for CI environments (at
the cost of not supporting interactive git commands).
By default /etc/pkg/FreeBSD.conf uses either the /quarterly or /latest pkg
builds, which are built against the latest minor release of FreeBSD for the
given ${ABI} string at the time they were last updated.
The nature of the shared binary packages means everyone (across all minor
versions of the same major version on the same architecture, all of which share
the same stable ABI) gets the same binary build.
There are however packages which depend on symbols exported by system-provided
libraries (rather than by other packages, which are always going to be in sync)
that *aren't* stable across minor releases, leaving packages like llvm
broken if you install the latest llvm from pkg's binary repos built against,
say, FreeBSD 13.1 while running FreeBSD 13.0.
The other option is to use the "snapshots" of the binary packages available upon
the release of each minor version, by using /release_0, /release_1, etc instead
of /quarterly or /latest, but then you're limited to the ports that were
available at that specific date and those old versions.
tl;dr just make sure we're always using the latest minor release for each major
version of FreeBSD we intend to support.
This works around an autocxx limitations where different types cannot
have the same name even if they live in different namespace.
ast::job_t conflicts with job_t.
This adds an implementation of fish_wcstoi in Rust, mirroring the one in
fish. As Rust does not have a string to number which infers the radix
(i.e. looks for leading 0x or 0), we add that manually.
In v3 several input parameters where renamed and since v4 it requires Node.js 16.
This resolves warnings about Node.js 12 and `set-output` being deprecated and
slated for removal in the `Lock threads` workflow.
This addresses the node v12 deprecation warning in the GitHub CI, caused by the
dependency on actions/checkout@v2.
While actions/checkout@v3 introduces some new features and changes some
defaults, the subset of features that we use should not be affected by this
migration.
The "breaking change" from v2 to v3 can be seen at [0]. Since we are tracking
only v2 without a dot release specified, we are already opting into any breakage
across minor versions, so really the only change of note is the node version
upgrade.
[0]: https://github.com/actions/checkout/compare/v2.4.2...v3.0.0
