- Removes closures and function calls for types that implement default:
```rust
// Change
let _my_str = get_str().unwrap_or(String::new);
// To
let _my_str = get_str().unwrap_or_default();
```
- Uses the `.cloned()/.copied()` methods where possible
- Use function pointer instead of simple closure
May improve performace, as closures generate more code, and this might
unlock some inlining opportunities.
- Use `find` instead of `position(..).next()`
- Use `any` instead of `position(..).next().is_some()/.is_none()`
- Use `first/next` instead of `get(0)/nth(0)`
- Prefer `for` loops over `while let` loops on iterators
May improve performance.
Avoids:
```
warning: the following packages contain code that will be rejected by a future version of Rust: ntapi v0.3.7
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 36`
```
Avoid using serde for mapping between Lua and Rust for the `Config`
struct.
This improves the build speed of the config crate by 2x; it goes down
from 30 seconds to 9 seconds on my 5950x.
I've had a couple of deadlock situations when invoking win32 apps
via wsl on my work machine. In those situations, the process that
we show in the titlebar is a short lived process that has likely
recently terminated, so I suspect something weird about either
dangling references or, given the deadlock-y nature of things,
maybe trying to reference ourselves.
This commit tries to defend against these by:
* Avoiding creating a ProcHandle for our own pid
* Releasing the toolhelper snapshot as soon as we have copied
out the list of pids that we need
Not sure that this will nail it, but it seems like it can't hurt.
When considering the fg process, we don't want a newly spawned
notepad.exe to show as the fg process in a cmd/pwsh pane, as it
runs async from the console and isn't attached to it.
We can extract the console handle from the process information and
use a 0 value handle to indicate win32 apps that are not attached
to any console.
We cannot compare console handle values directly: without probing
deeper into the handle we don't know that two differently valued
handles refer to different consoles, because a handle can be
duplicated into another with a different numeric value.
