This removes an awkward hack from ParseError::describe_with_prefix,
where it added errors for two error codes.
andor_in_pipeline was already there, so we just need bare_variable_assignment.
This file uses the questionable "self.somemethod(self.somefield)" pattern.
We should either set the functions free or stop passing redundant parameters.
Not sure.
For now fix one of them to avoid a string clone.
This implements input and input_common FFI pieces in input_ffi.rs, and
simultaneously ports bind.rs. This was done as a single commit because
builtin_bind would have required a substantial amount of work to use the input
ffi.
This will support rewriting the input machinery in Rust.
Note that while there are a lot of keys here, in practice this is very fast -
taking on the order of microseconds to populate.
We run __fish_enable_bracketed_paste on every shell prompt, and inside
edit_command_buffer. This protects from accidents when pasting control
characters, and makes sure the paste results in a single undo group.
Let's do the same for builtin read.
Found while doing the research for #10101
This was an issue with "--no-execute", which has no variables and
therefore no $HOME:
```fish
fish --no-execute /path/to/file
```
would say the error is in `~/path/to/file`.
Instead, since this is just for a message, we simply return the
filename without doing the replacement.
Fixes#10171
The "#[bench]" attribute is not allowed in stable Rust, so keep it behind
a new feature flag. Run on nightly Rust with
$ cargo bench --features=bechmark
test tests::encoding::bench::bench_convert_ascii ... bench: 125,988 ns/iter (+/- 1,128) = 1040 MB/s
Repeated
CARGO_LOG=cargo::core::compiler::fingerprint=trace cargo b
show that we always rebuild because of "compat.c". Not sure why.
Let's disable this for now so we can use the cache (for test targets etc.).
We rarely attach trait methods to stdlib types so this warning is unlikely to
be a true positive It is a false positive for the methods defined in future.rs.
It's not always obvious which method is selected when it's available in the
stdlib but I haven't seen a build failure yet. So let's disable the warning.
In future we might be able suppress it per method, see Rust issue 48919.
