Simonas Kazlauskas

In order to make an issue a good one for somebody to work on as their first contribution this lacks pointers towards the approximate area of where the changes should...

For whomever who tackles this https://near.zulipchat.com/#narrow/stream/295302-general/topic/publishing.20nearcore.20crates/near/411608655 is some relevant reading.

Hi. there was a request to do so in the past in https://github.com/nagisa/rust_libloading/issues/40, and nothing has meaningfully changed since then. If the goal is to only get access to an...

Some other approaches you could take are: use a `Pin`, `rental` or similar ecosystem crate to produce a self-referential structure, or generate code such as what e.g. [`bindgen` generates](https://github.com/rust-lang/rust-bindgen/blob/master/tests/expectations/tests/dynamic_loading_simple.rs) when...

Ambivalent. I’m not using `const`s or `static`s compared to `let`s and I therefore don’t really find it to be a pain point to have specify a type of these. I...

I’ve always been a strong proponent of the "intrinsic" functions that map down to a single instruction. For example, instead of writing `asm!("cpsid" ...)`, you’d call the function that would...

@gnzlbg yes, compiler is free to insert whatever code it wishes between the separate `asm!` statements to satisfy the constraints. For example it could decide to spill and reload the...

The intrinsics would be implemented in the backend, rather than libcore. While it is true, that it would increase burden when upgrading a backend, it wouldn’t be any greater than...

> Then there is also the issue that two consecutive asm! calls allow LLVM to insert code in between. This might not matter often in practice, but sounds a bit...

re __BKPT. Adding const generics is very likely to be backwards compatible, so we could expose `__BKPT()` -> `bktp 0` now and add a defaulted const generic later on without...