github-mirror/fish-shell
2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2024-12-27 04:33:38 +08:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity
3ae16a5b95
fish-shell/fish-rust/src/lib.rs

57 lines
1.1 KiB
Rust
Raw Normal View History

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)]
Silence some more clippy lints bool_assert_comparison is stupid, the reason they give is "it's shorter". Well, `assert!(!foo)` is nowhere near as readable as `assert_eq!(foo, false)` because of the ! noise from the macro. Uninlined format args is a stupid lint that Rust actually walked back when they made it an official warning because you still have to use a mix of inlined and un-inlined format args (the latter of which won't complain) since only idents can be inlined.
2023-03-05 14:54:17 +08:00
#![allow(clippy::bool_assert_comparison)]
#![allow(clippy::uninlined_format_args)]
#![allow(clippy::derivable_impls)]
Initial Rust commit
2023-01-15 06:56:24 +08:00
Port ASSERT_SORTED_BY_NAME to Rust
2023-02-26 23:34:03 +08:00
#[macro_use]
Port scoped_push to Rust
2023-02-11 20:31:42 +08:00
mod common;
lib.rs: sort modules
2023-03-26 01:43:56 +08:00
mod abbrs;
mod builtins;
Port color.cpp to Rust
2023-02-27 04:56:50 +08:00
mod color;
lib.rs: sort modules
2023-03-26 01:43:56 +08:00
mod env;
Port event.cpp to rust Port src/event.cpp to fish-rust/event.rs and some needed functions. Co-authored-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
2023-02-12 04:31:08 +08:00
mod event;
lib.rs: sort modules
2023-03-26 01:43:56 +08:00
mod expand;
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;
trace: Port trace to Rust
2023-03-28 23:59:51 +08:00
mod global_safety;
Port job_group to rust (#9608) More ugliness with types that cxx bridge can't recognize as being POD. Using pointers to get/set `termios` values with an assert to make sure we're using identical definitions on both sides (in cpp from the system headers and in rust from the libc crate as exported). I don't know why cxx bridge doesn't allow `SharedPtr<OpaqueRustType>` but we can work around it in C++ by converting a `Box<T>` to a `shared_ptr<T>` then convert it back when it needs to be destructed. I can't find a clean way of doing it from the cxx bridge wrapper so for now it needs to be done manually in the C++ code. Types/values that are drop-in ready over ffi are renamed to match the old cpp names but for types that now differ due to ffi difficulties I've left the `_ffi` in the function names to indicate that this isn't the "correct" way of using the types/methods.
2023-02-26 06:42:45 +08:00
mod job_group;
Implement some locale pieces This adds locale.rs, which maintains a locale struct sufficient to support printf.
2023-03-06 12:06:30 +08:00
mod locale;
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;
lib.rs: sort modules
2023-03-26 01:43:56 +08:00
mod path;
mod re;
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;
Reimplement termsize in Rust This is not yet adopted by fish.
2023-03-19 11:11:18 +08:00
mod termsize;
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;
trace: Port trace to Rust
2023-03-28 23:59:51 +08:00
mod trace;
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;
Rewrite wait handles and wait handle store in Rust
2023-03-14 10:23:31 +08:00
mod wait_handle;
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
Port fd_monitor tests to rust This shows some of the ugliness of the rust borrow checker when it comes to safely implementing any sort of recursive access and the need to be overly explicit about which types are actually used across threads and which aren't. We're forced to use an `Arc` for `ItemMaker` (née `item_maker_t`) because there's no other way to make it clear that its lifetime will last longer than the FdMonitor's. But once we've created an `Arc<T>` we can't call `Arc::get_mut()` to get an `&mut T` once we've created even a single weak reference to the Arc (because that weak ref could be upgraded to a strong ref at any time). This means we need to finish configuring any non-atomic properties (such as `ItemMaker::always_exit`) before we initialize the callback (which needs an `Arc<ItemMaker>` to do its thing). Because rust doesn't like self-referential types and because of the fact that we now need to create both the `ItemMaker` and the `FdMonitorItem` separately before we set the callback (at which point it becomes impossible to get a mutable reference to the `ItemMaker`), `ItemMaker::item` is dropped from the struct and we instead have the "constructor" for `ItemMaker` take a reference to an `FdMonitor` instance and directly add itself to the monitor's set, meaning we don't need to move the item out of the `ItemMaker` in order to add it to the `FdMonitor` set later.
2023-03-05 13:49:17 +08:00
// Don't use `#[cfg(test)]` here to make sure ffi tests are built and tested
mod tests;
Reference in New Issue Copy Permalink