thomcc

use core::{alloc::Layout, marker::PhantomData, ptr::NonNull};

/// Utility for performing several conceptually-separate allocations in a single
/// shot. Usage:
/// ```ignore
/// let (foos, numbers, bars): (NonNull<Foo>, NonNull<u32>, NonNull<Bar>) =
///     MultiAllocBuilder::<4>::new()
///         .push::<Foo>(Layout::array::<Foo>(num_foos).unwrap())
///         .push::<u32>(Layout::array::<u32>(num_numbers).unwrap())
///         .push::<Bar>(Layout::array::<Bar>(num_bars).unwrap())

thomcc

//! From a library I never finished. I should still make it it's own crate TBH.

macro_rules! parse_env {
    ($var_name:literal as $typ:ident) => {{
        const {
            match $crate::parse_env::dispatch::$typ(::core::env!($var_name).as_bytes(), ::core::None) {
                ::core::Some(v) => v,
                ::core::None => {
                    ::core::panic!(::core::concat!(
                        "error: the value in ",

thomcc

//! Implementation of [Lamport's bakery algorithm][bakery]. This is somewhat
//! interesting, because it's a mutex which can be implemented even if the
//! target only has atomic load/store, and no CAS (in principal it can be even
//! more general than this).
//!
//! [bakery]: https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
//!
//! Major caveat: This is not tested, and this algo is no longer appropriate
//! for modern code. Some variations of it can be useful in a thread pool, but
//! it's mostly useful to understand the concepts.

thomcc

use anyhow::Result;
use std::{
    path::{Path, PathBuf},
    sync::atomic::{AtomicBool, Ordering::Relaxed},
};

/// "Automagic" submodule wrangling (sync, clean, fix, etc)
///
/// Ported from rustc's `x.py` code, which runs something like this
/// automatically (even for `./x.py --help`)

thomcc

//! Sketch of a alternative way to implement the backend of `zeroize` (the part
//! that does memory zeroing).
//!
//! It should be:
//!
//! - More efficient, possibly much more (for byte arrays), as it can zero in
//!   the most efficient way available, rather than e.g. being forced to
//!   perform element-at-a-time writes (where "element" often is "byte").
//! - Still guaranteed even in the face of aggressive compiler optimizations
//!   as the semantics of volatile loads forbid the compiler from being able

thomcc

pub type Argb8888 = u32;

/// Average of 2 pixels, rounding up on tie.
///
/// It's fine if they're actually BGRA8888 or any other format, 
/// this treats every channel the same.
pub fn pixel_average(c0: Argb8888, c1: Argb8888) -> Argb8888 {
    (c0 | c1).wrapping_sub(((c0 ^ c1) >> 1) & 0x7f7f7f7f)
    // version that rounds down:
    // (c0 & c1).wrapping_add(((c0 ^ c1) >> 1) & 0x7f7f7f7f)

thomcc

use std::any::Any;

pub fn extract_message(err: &(dyn Any + Send)) -> String {
    fn extract(err: &(dyn Any + Send), max_tries: usize) -> String {
        if let Some(&s) = err.downcast_ref::<&'static str>() {
            return s.into();
        }
        if let Some(s) = err.downcast_ref::<String>() {
            return s.into();
        }

thomcc

//! initial version courtesy of @danielhenrymantilla.
//!
//! extended to support fns with args/return types,
//! visibility, #[attributes], unsafe, const, async,
//! extern "abi" ...
//!
//! left as an exercise for later (cuz it sux):
//! - generics?
//! - where clauses?
//! - probably other shit im missing

thomcc

/// Something like a `flat_map` over a fallible iterator.
///
/// Note that the `map` itself is not fallible.
///
/// See test at end of file for usage.
//
// TODO this should probably take `impl IntoIterator<IntoIter = I>` but the
// generics here are already so fucking complicated, and i'm worried that
// will cause inference errors

thomcc

/// Wrapper around an `impl std::error::Error` that makes it "mostly" clonable.
pub struct ClonableError<E> {
    error: Option<E>,
    // tbh these are all anybody cares about for Errors anyway.
    display: Box<str>,
    debug: Box<str>,
}

impl<E> Clone for ClonableError<E> {