GrabYourPitchforks

Memory<T> usage guidelines

This document describes the relationship between Memory<T> and its related classes (MemoryPool<T>, IMemoryOwner<T>, etc.). It also describes best practices when accepting Memory<T> instances in public API surface. Following these guidelines will help developers write clear, bug-free code.

First, a tour of the basic exchange types

• Span<T> is the basic exchange type that represents contiguous buffers. These buffers may be backed by managed memory (such as T[] or System.String). They may also be backed by unmanaged memory (such as via stackalloc or a raw void*). The Span<T> type is not heapable, meaning that it cannot appear as a field in classes, and it cannot be used across yield or await boundaries.

• Memory is a wrapper around an object that can generate a Span. For instance, Memory instances can be backed by T[], System.String (readonly), and even SafeHandle instances. Memory cannot be backed by "transient" unmanaged me

GrabYourPitchforks

Memory<T> API documentation and samples

This document describes the APIs of Memory<T>, IMemoryOwner<T>, and MemoryManager<T> and their relationships to each other.

See also the Memory<T> usage guidelines document for background information.

First, a brief summary of the basic types

• Memory<T> is the basic type that represents a contiguous buffer. This type is a struct, which means that developers cannot subclass it and override the implementation. The basic implementation of the type is aware of contigious memory buffers backed by T[] and System.String (in the case of ReadOnlyMemory<char>).

thomcc

{
	"unwrap or return": {
		"scope": "rust",
		"prefix": ["unwrap or return", "let if let"],
		"body": [
			"let $1 = if let ${3:Some($1)} = ${2:expr} {",
			"\t$1",
			"} else {",
			"\treturn ${0:Ok(())};",
			"};"

repi

msrv = "1.55.0"

# for `disallowed_method`: https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_method
disallowed-methods = [
    # std functions
    "std::env::temp_dir",        # we use the tempdir crate instead through ark_file_system::TempDir
    "std::env::home_dir",        # deprecated, and we use app_dirs2 crate
    "std::env::set_current_dir", # don't change the current working directory, it usually leads to shared sadness
    "std::env::var_os",          # use std::env::var and UTF-8 strings instead, including for paths
    "std::env::env_os",          # use std::env::env and UTF-8 strings instead, including for paths

Enichan

// coroutines for C adapted from Simon Tatham's coroutines
// https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
// 
// this implementation utilizes __VA_ARGS__ and __COUNTER__
// to avoid a begin/end pair of macros.
#include <stdlib.h>
#include <stdio.h>
#include <stdbool.h>

// modify this if you don't like the `self->name` format

regner

<?xml version='1.0' ?>

<!--
    Why is this one giant script instead of a bunch of smaller scripts?
    Mostly this comes down to BuildGraph and personal preference. As the language BuildGraph isn't
    really much of a programming language there is no easy way to use an IDE and jump between
    includes, find usages of variables, and just generally quickly search things. It was found to
    be easier to have a single large file that a developer can quickly jump up and down in when
    trying to understand what the BuildGraph script is doing.