I think it could be useful if we allowed the user to override the normal bootstrap code with something custom. This could be used in multiple niche cases, such as metamorphic contracts. Additionally, since Huff is often used for education purposes, some may want to write the bootstrap code themselves to better understand the contract deployment process.

I see two main ways of accomplishing this:

1. If a constructor contains the RETURN opcode in it, automatically omit the bootstrap code.
2. Add a command line flag to omit the bootstrap code.

I'd be happy to implement either of these myself, but want to make sure that the change would be well received first.

Overview

Currently the huff_cli -g flag tells the compiler to generate a solidity interface file at the same location as the source with an I prefix.

We should allow the -g flag to accept an optional string location of where to generate the output interfaces (with it by default being in the same location as each source file).

Hi !

The basefee opcode (0x48) is not suppoted by Huff.

I've never used, nor heard about anyone who use it, but it is needed for HyVM to be really exhaustive :) (it is currently implemented as a revert)

Thanks !

Overview

Attempts a fix for #196

Checklist

• [x] 1.1 Naming parameters as native solidity datatypes should lead to an error #define function balanceOf(address uint256) view returns (uint256 balance) => now errors with:

• [x] 1.2 A lack of a comma in a function definition should not lead to following datatypes affecting the function signature

  • This will not compile now as of 1.1

• [x] 2. You should be allowed to give a parameter a name that starts with "int" / "uint" / "bytes"

  • This was due to a bug in the PrimitiveEVMType that optimistically unwrapped on parsing the remaining bit of a string as a usize.

• [x] 3. You should be able to name dynamic parameters (string, bytes, <type>[], etc.)

Overview

Adds a new inspector to the test runner to detect calls to a cheatcode address. Cheatcodes can be invoked by sending a staticcall to 0x00000000000000000000000000000000bEefbabe with the following calldata layout:

╔═════════╦═══════════════╗
║ Offset  ║     Value     ║
╠═════════╬═══════════════╣
║ 0x00    ║ cheatcode_key ║
║ 0x20    ║ current_pc    ║
║ 0x40... ║ args          ║
╚═════════╩═══════════════╝

The first cheatcode is LOG, which allows logging stack items within Huff tests.

Will need to add a Huff tests cheatcode contract to Huffmate tomorrow:

#define macro LOG() = takes (1) {
    // Input stack:   [log_item]
    pc             // [pc, log_item]
    0x01           // [log_cheatcode, pc, log_item]
    0x00 mstore    // [pc, log_item]
    0x20 mstore    // [log_item]
    0x40 mstore    // []
    0x00 dup1      // [0x00, 0x00]
    0x60 dup2      // [0x00, 0x60, 0x00, 0x00]
    0x00000000000000000000000000000000bEefbabe
    gas            // [gas, beef_babe, 0x00, 0x60, 0x00, 0x00]
    staticcall pop // []
}

Overview

Adds a stripped down test suite to huff-rs, mainly for gas profiling and creating assertions.

Usage

CLI: huffc <contract_path> -t [-f <list|table|json>] [-m <TEST_NAME>]

Test syntax:

#[calldata("0x0000000000000000000000000000000000000000000000000000000000000020"), value(0x01)]
#define test MY_TEST() = takes (0) returns (0) {
    // test code
}

#define test MY_TEST_2() = takes (0) returns (0) {
    // test code
}

#define macro MY_MACRO() = takes (0) returns (0) {
    MY_TEST() // Tests cannot be invoked- this will throw an error.
}

Checklist

• [x] Create a test runner that utilizes revm
  • [x] Tests for the runner
  • [x] Configurable test environment (gas limit, chain id, hardfork, call value, etc.)
  • [ ] Simple input fuzzer (? - not necessarily needed, might be nice for fuzzed gas profiling.)
• [x] Implement test macros into the lexer / parser
  • [x] Restrict regular macros / functions from invoking test macros
• [x] Add a subcommand / flag to the CLI to run the test suite
• [x] Clean up
  • [x] Proper errors
  • [x] README

Overview

Please provide a short description here and review the requirements below.

I was having probs removing the old huffc npm package and didnt even realize it at first because it seemed to take when i ran yarn global remove huffc and also i didnt know what version we were on or that the --help files look different now. Finally after some headbanging I realized i was still running the old version and went back and tried removing it again but with sudo this time, and that worked.

Thought I'd add something in the docs here to help others in case they have a similar experience.

Overview

When parsing, we need to expand macros to make code generation as easy as possible.

Macro expansion refers to the process of taking an invocation, and expanding to its relevant opcodes, with the arguments substituted. This is a crucial part of eventually compiling Huff code, whether we include it in parsing or not.

An example of macro expansion:

#define macro EXPAND_ME() = takes(0) returns(0) {
    0x02 0x01 add
}

#define macro MAIN() = takes(0) returns(0) {
   0x01 0x02 sub
   EXPAND_ME()
}

Once the compiler has turned the code into tokens, the macro expansion and parsing will begin. The parser will begin parsing the macros, and notice there is an invocation to the EXPAND_ME macro. It will 'expand,' or substitute, the necessary opcodes into the main macro. If we represent the newly parsed code in Huff, it would look like below.

#define macro MAIN() = takes(0) returns(0) {
   0x01 0x02 sub
   0x02 0x01 add
}

The alternative to doing this is in code generation. Instead of parsing the expansions, we can look for invocations in code generation.

Expanding the macros at the parsing stage is somewhat better than doing it add the code generation stage as it means we do not have to track the invocations in vectors, and have ambiguity regarding ordering.

Overview

Currently, we're returning errors that don't give the developer enough information. #33 added slightly more specific error messages for development purposes, but codemap-diagnostic (suggested by @sudovirtual) provides much more verbose feedback.

We should create an error handling function or struct in huff_utils/error.rs to make it as easy as possible to create diagnostic messages and emit them throughout the codebase.

Overview

Previously, the function definition in the AST allowed a function to have multiple types.

It was changed to only allow one single type, as multiple don't make sense.

A function definition not having a return type should be an invalid syntax.

Overview

Right now (master @ 5fd1e325625612a931ef10e428bf07197399b840), the huff_lexer incorrectly parses bytes / hex number tokens.

Failing Test

#[test]
fn parses_bytes() {
    let source = "0xDDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF";
    let mut lexer = Lexer::new(source);
    assert_eq!(lexer.source, source);

    // Try to parse the bytes token (assuming that it is a single token)
    let tok = lexer.next();
    let unwrapped = tok.unwrap().unwrap();
    let bytes_span = Span::new(0..source.len());
    assert_eq!(unwrapped, Token::new(TokenKind::Ident(source), bytes_span));
    assert_eq!(lexer.span, bytes_span);

    // We covered the whole source
    assert_eq!(lexer.span.end, source.len());
    assert!(lexer.eof);
    assert!(lexer.next().is_none());
}

Expected Result

tok = Token { kind: Ident("0xDDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF"), span: Span { start: 0, end: 66 } }

Or a dedicated TokenKind variant for bytes / hex tokens.

Actual Result

tok = Token { kind: Num(0), span: Span { start: 0, end: 1 } }

Suspected Reason for Issue

The lexer dyn_consumes all valid ascii digits when it comes across what it thinks is a TokenKind::Num. When dyn_consume hits the second character of a bytes / hex number token, x, it completes, splitting the bytes / hex number token into two parts: The TokenKind::Num(0) and the TokenKind::Ident("xDDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF"). Some extra logic needs to be added to this match arm in order to correctly lex these tokens.

The following snippets are identical in theory:

#define constant SWAG = 0x00

#define macro M(slot) = {
	<slot> sload 0x00 mstore 0x14 0x00 return
}

#define macro MAIN() = {
	M(SWAG)
}

#define constant SWAG = FREE_STORAGE_POINTER()

#define macro M(slot) = {
	<slot> sload 0x00 mstore 0x14 0x00 return
}

#define macro MAIN() = {
	M(SWAG)
}

But the latter errors without context with Error: Storage Pointers Not Derived.

Seems to be a bug?

Overview

With some minor tweaks and shims, huff_core can be compiled to a wasm target and then be used with JavaScript which even works in the browser.

1. Remove unused dependency prop-test which is not wasm compatible
2. Shim for into_par_iter() for creating parallel iterators. Not supported on wasm but can just fallback to a regular iterator.
3. SystemTime::now panics on wasm as it's not implemented so use a u64 unix timestamp on wasm target instead.

The biggest change required was to refactor out the file system stuff and create an alternative "in memory" version which loads files from a HashMap instead of from disk.

With that all working, I put together a new module huff_js which includes JavaScript bindings so you can interface with the compiler via a JSON interface similar to standard json in solc.

This would make Huff more accessible to integrate with web-based tools like https://www.evm.codes/ which is why I started looking at this in the first place. It would be awesome to have Huff available on there.

Example JS usage:

const { compile } = require('./pkg/huffc.js')

let files = {
    "add.huff": "#define function add(uint256,uint256) nonpayable returns (uint256)\n" +
        "\n" +
        "#define macro MAIN() = {\n" +
        "   // Load our numbers from calldata and add them together.\n" +
        "   0x04 calldataload // [number1]\n" +
        "   0x24 calldataload // [number2]\n" +
        "   add               // [number1+number2]\n" +
        "   // Return our new number.\n" +
        "   0x00 mstore // Store our number in memory.\n" +
        "   0x20 0x00 return // Return it.\n" +
        "}\n"
}

const result = compile({
    files,
    sources: ['add.huff'],
    // constructor_args: "..."
});

console.log(result)

Outputs:

{
  errors: undefined,
  contracts: Map(1) {
    'add.huff' => {
      bytecode: '600f8060093d393df36004356024350160005260206000f3',
      runtime: '6004356024350160005260206000f3',
      abi: [Object]
    }
  }
}

Overview

When the parent path doesn't start with a ./ or ../ and the child starts with a ../ the calculated path is incorrect.

e.g.

files::FileSource::localize_file("examples/ERC20.huff", "../random_dir/Address.huff")

// returns    "../examples/random_dir/Address.huff"
// expected   "./random_dir/Address.huff"

Fixed by checking if parent starts with a . and if not prefixing it with one.

Added a regression test.

huffup, when used with --path to install a local repo does not work for me. The error is:

huffup: command failed: ln -s PWD/target/release/huffc HUFF_BIN_DIR/huffc

because HUFF_BIN_DIR/huffc already exists.

I think that we want to link PWD/target/release/huffc with HUFF_BIN_DIR/huffc and not HUFF_BIN_DIR/huff.

https://github.com/huff-language/huff-rs/blob/e0f640f12373e0a98edfc1e33eb4cc40c6bec129/huffup/huffup#L78