fish-shell/fish-rust/src/lib.rs

#![allow(non_camel_case_types)]
#![allow(dead_code)]
#![allow(non_upper_case_globals)]
#![allow(clippy::needless_return)]
#![allow(clippy::manual_is_ascii_check)]

mod common;
mod fd_monitor;
mod fd_readable_set;
mod fds;
#[allow(rustdoc::broken_intra_doc_links)]
#[allow(clippy::module_inception)]
#[allow(clippy::new_ret_no_self)]
#[allow(clippy::wrong_self_convention)]
#[allow(clippy::needless_lifetimes)]
mod ffi;
mod ffi_init;
mod ffi_tests;
mod flog;
mod future_feature_flags;
mod nix;
mod parse_constants;
mod redirection;
mod signal;
mod smoke;
mod threads;
mod timer;
mod tokenizer;
mod topic_monitor;
mod util;
mod wchar;
mod wchar_ext;
mod wchar_ffi;
mod wgetopt;
mod wutil;

mod abbrs;
mod builtins;
mod env;
mod re;
Initial Rust commit 2023-01-15 06:56:24 +08:00			`#![allow(non_camel_case_types)]`
			`#![allow(dead_code)]`
			`#![allow(non_upper_case_globals)]`
			`#![allow(clippy::needless_return)]`
clippy: silence manual_is_ascii_check 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. 2023-02-05 18:47:20 +08:00			`#![allow(clippy::manual_is_ascii_check)]`
Initial Rust commit 2023-01-15 06:56:24 +08:00
Port scoped_push to Rust 2023-02-11 20:31:42 +08:00			`mod common;`
Port fd_monitor (and its needed components) I needed to rename some types already ported to rust so they don't clash with their still-extant cpp counterparts. Helper ffi functions added to avoid needing to dynamically allocate an FdMonitorItem for every fd (we use dozens per basic prompt). I ported some functions from cpp to rust that are used only in the backend but without removing their existing cpp counterparts so cpp code can continue to use their version of them (`wperror` and `make_detached_pthread`). I ran into issues porting line-by-line logic because rust inverts the behavior of `std::remove_if(..)` by making it (basically) `Vec::retain_if(..)` so I replaced bools with an explict enum to make everything clearer. I'll port the cpp tests for this separately, for now they're using ffi. Porting closures was ugly. It's nothing hard, but it's very ugly as now each capturing lambda has been changed into an explicit struct that contains its parameters (that needs to be dynamically allocated), a standalone callback (member) function to replace the lambda contents, and a separate trampoline function to call it from rust over the shared C abi (not really relevant to x86_64 w/ its single calling convention but probably needed on other platforms). I don't like that `fd_monitor.rs` has its own `c_void`. I couldn't find a way to move that to `ffi.rs` but still get cxx bridge to consider it a shared POD. Every time I moved it to a different module, it would consider it to be an opaque rust type instead. I worry this means we're going to have multiple `c_void1`, `c_void2`, etc. types as we continue to port code to use function pointers. Also, rust treats raw pointers as foreign so you can't do `impl Send for * const Foo` even if `Foo` is from the same module. That necessitated a wrapper type (`void_ptr`) that implements `Send` and `Sync` so we can move stuff between threads. The code in fd_monitor_t has been split into two objects, one that is used by the caller and a separate one associated with the background thread (this is made nice and clean by rust's ownership model). Objects not needed under the lock (i.e. accessed by the background thread exclusively) were moved to the separate `BackgroundFdMonitor` type. 2023-02-18 09:21:44 +08:00			`mod fd_monitor;`
Initial Rust commit 2023-01-15 06:56:24 +08:00			`mod fd_readable_set;`
			`mod fds;`
rust: silence warnings on auto-generated FFI bindings 2023-02-05 07:59:44 +08:00			`#[allow(rustdoc::broken_intra_doc_links)]`
			`#[allow(clippy::module_inception)]`
			`#[allow(clippy::new_ret_no_self)]`
			`#[allow(clippy::wrong_self_convention)]`
Add more clippy exceptions for ffi module 2023-02-12 22:46:44 +08:00			`#[allow(clippy::needless_lifetimes)]`
Initial Rust commit 2023-01-15 06:56:24 +08:00			`mod ffi;`
			`mod ffi_init;`
Add an FFI test facility This allow testing Rust functions (from fish_tests.cpp) which need to cross the FFI. See the example in smoke.rs. 2023-01-16 06:56:04 +08:00			`mod ffi_tests;`
Initial Rust commit 2023-01-15 06:56:24 +08:00			`mod flog;`
Port future_feature_flags.cpp to Rust 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. 2023-02-03 23:34:29 +08:00			`mod future_feature_flags;`
Port timer.cpp to rust 2023-02-15 05:54:18 +08:00			`mod nix;`
Port parse_constants.h to Rust 2023-02-05 16:35:06 +08:00			`mod parse_constants;`
Port redirection.cpp to Rust 2023-02-04 18:21:42 +08:00			`mod redirection;`
Initial Rust commit 2023-01-15 06:56:24 +08:00			`mod signal;`
			`mod smoke;`
Port fd_monitor (and its needed components) I needed to rename some types already ported to rust so they don't clash with their still-extant cpp counterparts. Helper ffi functions added to avoid needing to dynamically allocate an FdMonitorItem for every fd (we use dozens per basic prompt). I ported some functions from cpp to rust that are used only in the backend but without removing their existing cpp counterparts so cpp code can continue to use their version of them (`wperror` and `make_detached_pthread`). I ran into issues porting line-by-line logic because rust inverts the behavior of `std::remove_if(..)` by making it (basically) `Vec::retain_if(..)` so I replaced bools with an explict enum to make everything clearer. I'll port the cpp tests for this separately, for now they're using ffi. Porting closures was ugly. It's nothing hard, but it's very ugly as now each capturing lambda has been changed into an explicit struct that contains its parameters (that needs to be dynamically allocated), a standalone callback (member) function to replace the lambda contents, and a separate trampoline function to call it from rust over the shared C abi (not really relevant to x86_64 w/ its single calling convention but probably needed on other platforms). I don't like that `fd_monitor.rs` has its own `c_void`. I couldn't find a way to move that to `ffi.rs` but still get cxx bridge to consider it a shared POD. Every time I moved it to a different module, it would consider it to be an opaque rust type instead. I worry this means we're going to have multiple `c_void1`, `c_void2`, etc. types as we continue to port code to use function pointers. Also, rust treats raw pointers as foreign so you can't do `impl Send for * const Foo` even if `Foo` is from the same module. That necessitated a wrapper type (`void_ptr`) that implements `Send` and `Sync` so we can move stuff between threads. The code in fd_monitor_t has been split into two objects, one that is used by the caller and a separate one associated with the background thread (this is made nice and clean by rust's ownership model). Objects not needed under the lock (i.e. accessed by the background thread exclusively) were moved to the separate `BackgroundFdMonitor` type. 2023-02-18 09:21:44 +08:00			`mod threads;`
Port timer.cpp to rust 2023-02-15 05:54:18 +08:00			`mod timer;`
Port parse_constants.h to Rust 2023-02-05 16:35:06 +08:00			`mod tokenizer;`
Initial Rust commit 2023-01-15 06:56:24 +08:00			`mod topic_monitor;`
Port util.cpp to Rust 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. 2023-01-31 04:23:01 +08:00			`mod util;`
Initial Rust commit 2023-01-15 06:56:24 +08:00			`mod wchar;`
			`mod wchar_ext;`
			`mod wchar_ffi;`
			`mod wgetopt;`
Port fish_wcstoi to Rust 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. 2023-01-15 08:34:49 +08:00			`mod wutil;`
Implement builtin_wait in Rust This implements builtin_wait in Rust. 2023-01-16 11:52:08 +08:00
abbr: port abbreviation and abbr builtin to rust 2023-02-25 00:00:05 +08:00			`mod abbrs;`
Implement builtin_wait in Rust This implements builtin_wait in Rust. 2023-01-16 11:52:08 +08:00			`mod builtins;`
abbr: port abbreviation and abbr builtin to rust 2023-02-25 00:00:05 +08:00			`mod env;`
			`mod re;`