| #include <stdio.h> | |
| #include <stdint.h> | |
| #include <ISmmPlugin.h> | |
| #include <igameevents.h> | |
| #include <sh_vector.h> | |
| #include <inetchannelinfo.h> | |
| class RatePlugin : public ISmmPlugin, public IMetamodListener | |
| { | |
| public: |
| # What you need to write low level Rust code | |
| * Avoid cargo, it it may seem tempting, but you'll just keep running into untested code paths and design flaws; it's not meant to do it. | |
| * Using a target specification to describe your platform is recommended, and you'll likely need one for one reason or another anyways (example: https://github.com/hackndev/zinc/blob/master/thumbv6-none-eabi.json ). Pass it to rustc via --target=target.json | |
| * You wan work without the standard library, by following those instructions: https://doc.rust-lang.org/book/no-stdlib.html | |
| * Inline assembly (asm!) blocks are fed directly into LLVM and have horrible error checking, tread lightly and verify the output. | |
| * LLVM can end up generating dodgy versions of certain instructions on certain versions, it may for example turn "lgdt" into the utterly useless 16-bit version (which truncates the upper 8 bits of the address). Specify operand sizes. | |
| * An "intel" option is supported, but it seems to be somewhat dodgy (for example, it seemed to d |
| {date, hash}: | |
| let | |
| pkgs = import <nixpkgs> {}; | |
| stdenv = pkgs.stdenv; | |
| libPath = stdenv.lib.makeLibraryPath [ pkgs.zlib ]; | |
| in stdenv.mkDerivation rec { | |
| name = "rust-nightly"; | |
| version = "${date}"; | |
| src = pkgs.fetchurl { |
| {date, hash}: | |
| let | |
| pkgs = import <nixpkgs> {}; | |
| stdenv = pkgs.stdenv; | |
| in stdenv.mkDerivation rec { | |
| name = "rust-nightly-${date}"; | |
| src = pkgs.fetchurl { | |
| url = "http://static.rust-lang.org/dist/${date}/rust-nightly-x86_64-unknown-linux-gnu.tar.gz"; | |
| sha256 = hash; |
Stop marking the entire interior of unsafe functions as unsafe, thus requiring unsafe functions to have smaller inner unsafe blocks holding only the operations which are actually unsafe.
Currently, each unboxed closure definition generates its own unique type, functions however do not exhibit the same behavior. This RFC proposes the addition of a unique compiler-generated zero-sized anonymous type for each function definition.
The current fn() types represent something close to &'static Code, which means that safely representing a function pointer into code with a non-static lifetime is impossible. This RFC describes the addition of the ability to assign a non-static lifetime to the fn() type, which would allow fn():'a to represent a type similar to &'a Code.
