https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/Evolving.20trait.20hierarchies.20.28goals.23393.29/near/546690945

What today's RFC prescribes enables the following

So we decided that we need to have reborrowing desugared only in MIR. THIR propagates the reborrowing adjustment down to the MIR building stage.

struct task_struct

Xiangfei Ding2024

Migration guide for shorter if let scope

The crater run is executed by assuming the iflet_rescope feature gate throughout in order to assess the impact and proposals for lints, compiler assistance and migration support.

*** IR Dump After InstCombinePass on ZN4core5slice29LTimplu20u5bTu5d$GT9as_chunks17h6ae92312da7e6eadE * ** ; Function Attrs: inlinehint nonlazybind uwtable define internal fastcc void @"_ZN4core5slice29_LTimplu20u5b$T$u5dGT9as_chunks17h6ae92312da7e6eadE"(ptr noa lias nocapture noundef sret({ { ptr, i64 }, { ptr, i64 } }) align 8 dereferenceable(32) %0, ptr noalias noundef no nnull readonly align 1 %1, i64 noundef %2, ptr noalias noundef readonly align 8 dereferenceable(24) %3) unnamed_ad dr #0 { %5 = alloca { { ptr, i64 }, { ptr, i64 } }, align 8 %6 = and i64 %2, -4 call void @llvm.lifetime.start.p0(i64 32, ptr nonnull %5) call fastcc void @"_ZN4core5slice29_LTimplu20u5b$T$u5dGT$8split_at17h1d8e98916f00effaE"(ptr noalias nocapture noundef nonnull sret({ { ptr, i64 }, { ptr, i64 } }) align 8 dereferenceable(32) %5, ptr noalias noundef nonnull readonly align 1 %1, i64 noundef %2, i64 noundef %6, ptr noalias noundef nonnull readonly align 8 dereferenceable(24) %3)%7 = load ptr, ptr %5, align 8, !nonnull !3, !align !4, !noundef !3%8 = getelementptr inbounds { ptr, i64 }, ptr %5, i64 0, i32 1%9 = load i64, ptr %8, align 8, !noundef !3%10 = getelementptr inbounds { { ptr, i64 }, { ptr, i64 } }, ptr %5, i64 0, i32 1%11 = load ptr, ptr %10, align 8, !nonnull !3, !align !4, !noundef !3%12 = getelementptr inbounds { { ptr, i64 }, { ptr, i64 } }, ptr %5, i64 0, i32 1, i32 1%13 = load i64, ptr %12, align 8, !noundef !3call void @llvm.lifetime.end.p0(i64 32, ptr nonnull %5)%14 = lshr exact i64 %9, 2store ptr %7, ptr %0, align 8%15 = getelementptr inbounds { ptr, i64 }, ptr %0, i64 0, i32 1store i64 %14, ptr %15, align 8%16 = getelementptr inbounds { { ptr, i64 }, { ptr, i64 } }, ptr %0, i64 0, i32 1store ptr %11, ptr %16, align 8%17 = getelementptr inbounds { { ptr, i64 }, { ptr, i64 } }, ptr %0, i64 0, i32 1, i32 1store i64 %13, ptr %17, align 8ret void}

Marigold values developer and user experiences when it comes to Tezos ecosystem. We are very excited about the upcoming SORU announcement and have started our pilot programme to develop kernels on top of SORU. Here we would like to share our thoughts. Developer experience Software development kit (SDK) SORU has a well-documented Rust SDK. Although there are rough edges in APIs, we have listed them as issue tickets in Pistachio repository and we are progressively proposing the improvements and implementing them. Observability SORU kernels at the moment must be run on top of SORU nodes which interpret the kernels. However, kernel execution mostly remain silent. There is a lack of venue to observe the progress of the kernel execution, logging and error reporting. From the point of view of operation and engineering, this poses a major challenge in tracking and identifying potential problems. We would like to propose the following improvements:

Ticket transfer Tickets are important. On Tezos blockchain, they can be used as non-fungible tokens in smart contracts and smart rollups. There has been an overhaul of the ownership system of Tezos tickets in the latest protocol proposal. In this blog post, we will demonstrate how tickets can be transferred between different entities on the Tezos blockchain in the new proposal. From an originated contract to an implicit account Naturally, the lifecycle of a ticket starts from construction of it by a Tezos smart contract. It may be held by an implicit account, like a promise to a service to a person behind the implicit account. To "hand out" this ticket, the contract just needs to construct a contract (ticket content_ty) contract handle to the receiving implicit account, given that content_ty is the type of the ticket content. For instance, we may transfer a string ticket with the following instructions. # stack: address : <...>

Archlinux pacman -Syu wasi-libc wasi-compiler-rt wabt Installer in Rust src/lib.rs #![no_std] #[panic_handler]

Gas for Tezos protocol developers Every transaction comes with a cost attached called gas. Whenever you send a transaction, of various types of manager operation, you will mostly come across gas in the transaction receipt. It also appears in the wallet transaction interface, where it may ask you for a maximally allowable gas value for this transaction. For instance, you may see this if you submit a transaction through octez-client. This sequence of operations was run: Manager signed operations: From: [PUBLIC_KEY_HASH] .... snip .... Gas limit: 3689 <<<< snip >>>> Transaction: