Thom Chiovoloni
Thom Chiovoloni
I think it is not worth it to define a custom trait, but there's no reason we couldn't support `core::alloc::Allocator` once it is stable.
It seems like if you have: - crate A with `crate-type=["cdylib", "rlib"]`, that emits `println!("cargo:rustc-cdylib-link-arg=...")` in its build.rs, and - crate B of type `cdylib` that depends on crate A...
This code is entirely within cfgs for xous, which is tier 3, so we usually just let the target maintainers for such targets do what they need so long as...
Note: Pretty sure that this is a breaking API change, since someone with `default-features=false` who used the `num-complex` functionality would break. Given that, perhaps it's better to *not* have it...
I have this bug too, it reproduces easily macOS and Linux on every folder I've tried.
Looks fine to me. This is part of an approved RFC and is doc-only so I don't think it needs any FCP or anything. @bors r+ rollup
`rustc --print deployment-target` works as of 1.71.0 (https://github.com/rust-lang/rust/pull/105354)
I'd submit a PR but it's unclear if the right behavior is to link both, just the fallback path, or what. I suppose at worst this issue can maybe point...
I'm surprised it worked well for Rust, given that nearly any non-trivial Rust program will use static TLS (via `std::thread_local!`), which isn't supported by MemoryModule (it is somewhat supported by...
It seems that mimalloc hit this same problem, on aarch64 apple targets LLVM just reads the wrong register: https://github.com/microsoft/mimalloc/issues/343#issuecomment-763272369.