Moving the "make empty ToLowercase iterator" logic to within the
`unwrap_or_else()` instead of always generating it brings most of the speedup;
unrolling the recursive call brings in the rest.
Using `c.is_uppercase()` instead of getting the iterator and checking if the
first (and only) lowercase letter of the sequence is the same as the original
input is 5-8x faster (measured via criterion against `/usr/share/dict/words`).
(Additional benefit of forcibly inlining the now iterator-based comparison not
taken into account; this necessitated changing from a closure to a local
function as the inline attribute on closures is not yet supported with the
stable compiler toolchain.)
This is still suboptimal because we are allocating a vector of indices to be
removed (but allocation-free in the normal case of no duplicates) but
significantly better than the previous version of the code that duplicated the
strings (which are larger and spread out all over the heap).
The ideal code (similar to what we had in the C++ version, iirc) would look like
this, but it's not allowed because the borrow checker hates you:
```
fn unique_in_place_illegal(comps: &mut Vec<Completion>) {
let mut seen = HashSet::with_capacity(comps.len());
let mut idx = 0;
while idx < comps.len() {
if !seen.insert(&comps[idx].completion) {
comps.remove(idx);
continue;
}
idx += 1;
}
}
```
This was an sh-script that just invoked fish again.
I can see how we could implement it in another language to avoid the
fish under test corrupting the results, but it literally invoked the
fish under test anyway.
Mostly we pass on the options - otherwise they would be ignored.
For `clear`, we do need the full checks, because that will
prompt *before* running the builtin.
But this makes it easier to eventually move that logic into the builtin
If a semicolon-delimited list of CSI parameters contained an (invalid) long
sequence of ascii numeric characters, the original code would keep multiplying
by ten and adding the most recent ones field until the `params[count][subcount]`
u32 value overflowed.
This was found via automated fuzz testing of the `try_readch()` routine against
a corpus of some proper/valid CSI escapes.
This lets us call into the entirety of the prior `readch()` with an exhaustible
input stream without panicking on the `unreachable!()` call. The previous
functionality is kept under the old name by calling `try_readch()` with the
`blocking` parameter set to `true` (100% same behavior as before).
While the `try_readch(false)` entrypoint isn't used directly by the current fish
codebase, it is required in order to automate input reader tests without the
overhead and complexity of running the test harness in a tty emulator emulator
like pexpect or tmux, which moreover necessitates out-of-process testing – which
is incompatible with most perf-guided testing harnesses.
I hope to be able to upstream harness integrations using this entry point in the
near future.
These are pretty basic, but get us roughly up to the level of the
official completions (that are also incomplete and offer disabled
options).
Fixes#10858
`print_help` is a hacky-wacky function used to support the `--help` command
of `fish_key_reader` and others. The Rust version panics on an error; fix
that and make it print more useful help messages.
* feat(function): move cmd completion function to a separate file
* feat(completion): support wine cmd subcommand
* feat(completion): support wine control subcommand
* feat(completion): support wine eject subcommand
* feat(completion): support wine explorer subcommand
* feat(completion): support wine explorer subcommand for desktops
* feat(completion): support wine start subcommand
* feat(completion): support wine winemenubuilder subcommand
* feat(completion): support wine winepath subcommand
* fix(function): rename function for cmd argument completion
* feat(function): implement function to complete registry keys
* feat(completion): support wine regedit subcommand
* feat(function): add top-level key descriptions
* fix(completion): remove redundant comment
* feat(completion): support wine msiexec subcommand
* refactor(completion): group code into functions
* feat(completion): enhance subcommand descriptions
I'm guessing this was missed in the port because there were comments referencing
using a hash set to perform the deduplication but there was no hashset. (The
TODO was added later.)
This caught an incorrect description for process/job exit handlers for ANY_PID
(now removed) which has been replaced with a message stating the handler is for
any process exit event.
The previous approach of "treat this field as an `Option<NonZeroU32>` and
remember to check `p.has_pid()` before accessing it" was a mix of C++ and rust
conventions and led to some bugs or incorrect behaviors.
* `jobs -p` would previously print both the (correct) external pid and the
(incorrect) internal value of `0` if a backgrounded command contained a
fish function (e.g. `function foo; end; cat | foo &; jobs`)
* Updating/calculating job cpu time and usage was incorrectly including all of
fish's cpu usage/time for each function/builtin member of the job pipeline.
Closes#10832
ctrl-r ctrl-s ctrl-s
Attemps to go before the beginning and asserts out. Instead refuse to
do that.
(there's some weirdness where it can reduce the pager to the first
entry if you keep pressing, which I haven't found yet, but that's better than *crashing*)
CMake Warning (dev) at cmake/Tests.cmake:56 (add_custom_command):
Exactly one of PRE_BUILD, PRE_LINK, or POST_BUILD must be given. Assuming
POST_BUILD to preserve backward compatibility.
Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
So we just keep it the same.
These are another way to spell the same thing that doesn't match what
`bind` would print.
They're also not documented and tested thoroughly.
Since they are just small shortcuts and unreleased we can just remove
them.
Fixes#10845
This has the side effect of changing the order of completions for a bare `git
diff` to show modified files before revisions; previously they came at the very
end after all revisions, stashes, local branches, remote branches, and tags.
That seems sensible to me?
As I understand the completions file, it seems to me that the intention was for
`git diff src/` to only show modified files to begin with it
previously/currently shows them all, so we might want to add a `-n 'not ...'`
condition for `git diff` to prevent that.
