A release! Congratulations!

I gave it a test on my computer which is running Ubuntu in WSL2 on Windows 10.

Here's the result:

% init.erl
-module(init).
-export([start/0]).

start() ->
    erlang:display(hello_lumen).

$ lumen compile
   Compiling /home/louis/src/lpil/learning/erlang/lumen_test/init.erl
fish: 'lumen compile' terminated by signal SIGSEGV (Address boundary error)

Let me know if I can help in future with debugging + testing. Cheers

init.erl

-module(init).
-export([start/0]).
-import(erlang, [demonitor/1, display/1, process_info/2, spawn_monitor/1]).

start() ->
  {ChildPid, MonitorReference} = spawn_monitor(fun () ->
    ok
  end),
  wait(2),
  Message = {'DOWN', MonitorReference, process, ChildPid, normal},
  display(has_message(Message)),
  display(demonitor(MonitorReference)),
  display(has_message(Message)).

has_message(Message) ->
  Messages = process_info(self(), messages),
  lists:member(Message, Messages).

wait(Milliseconds) ->
  receive
  after Milliseconds -> ok
  end,
  ok.

Error

Compiling tests/lib/erlang/demonitor_1/with_reference/with_monitor/does_not_flush_existing_message/init.erl
loc("tests/lib/erlang/demonitor_1/with_reference/with_monitor/does_not_flush_existing_message/init.erl":11:11): error: operand #0 does not dominate this use


module @init {
  eir.func @lumen_eh_personality() -> i32 attributes {std.varargs = true}
  eir.func @"init:start-fun-0-0/0"() -> !eir.term attributes {personality = @lumen_eh_personality} {
    %0 = eir.constant.atom #eir.atom<{ id = 71, value = 'ok' }>
    %1 = eir.cast %0 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    eir.return %1 : !eir.term
  }
  eir.func @"init:start/0"() -> !eir.term attributes {personality = @lumen_eh_personality} {
    %0 = eir.closure @"init:start-fun-0-0/0"() {arity = 0 : i8, env_len = 0 : i8, index = 0 : i32, module = #eir.atom<{ id = 62, value = 'init' }>, old_unique = 0 : i32, unique = "\FD\D4\0CF\BB$\CEg\00\00\00\00\00\00\00\00"} : () -> !eir.term
    %1 = eir.call @"erlang:spawn_monitor/1"(%0) : (!eir.term) -> !eir.term
    eir.br ^bb11(%1 : !eir.term)
  ^bb1(%2: !eir.term):  // pred: ^bb9
    %3 = eir.call @"erlang:display/1"(%2) : (!eir.term) -> !eir.term
    eir.br ^bb2(%3 : !eir.term)
  ^bb2(%4: !eir.term):  // pred: ^bb1
    %5 = eir.call @"erlang:demonitor/1"(%31) : (!eir.term) -> !eir.term
    eir.br ^bb3(%5 : !eir.term)
  ^bb3(%6: !eir.term):  // pred: ^bb2
    %7 = eir.call @"erlang:display/1"(%6) : (!eir.term) -> !eir.term
    eir.br ^bb4(%7 : !eir.term)
  ^bb4(%8: !eir.term):  // pred: ^bb3
    %9 = eir.constant.atom #eir.atom<{ id = 74, value = 'DOWN' }>
    %10 = eir.cast %9 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    %11 = eir.constant.atom #eir.atom<{ id = 75, value = 'process' }>
    %12 = eir.cast %11 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    %13 = eir.constant.atom #eir.atom<{ id = 76, value = 'normal' }>
    %14 = eir.cast %13 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    %15 = eir.tuple(%10, %31, %12, %30, %14) {alloca = false} : (!eir.term, !eir.term, !eir.term, !eir.term, !eir.term) -> !eir<"box<!eir<"tuple<5x!eir.term">>">
    %16 = eir.cast %15 : !eir<"box<!eir<"tuple<5x!eir.term">>"> to !eir.term {from = !eir<"box<!eir<"tuple<5x!eir.term">>">, to = !eir.term}
    %17 = eir.call @"init:has_message/1"(%16) : (!eir.term) -> !eir.term
    eir.br ^bb5(%17 : !eir.term)
  ^bb5(%18: !eir.term):  // pred: ^bb4
    %19 = eir.call @"erlang:display/1"(%18) : (!eir.term) -> !eir.term
    eir.return %19 : !eir.term
  ^bb6(%20: !eir.term):  // pred: ^bb7
    %21 = eir.constant.atom #eir.atom<{ id = 46, value = 'error' }>
    %22 = eir.cast %21 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    %23 = eir.constant.atom #eir.atom<{ id = 200, value = 'badmatch' }>
    %24 = eir.cast %23 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    %25 = eir.tuple(%24, %35) {alloca = false} : (!eir.term, !eir.term) -> !eir<"box<!eir<"tuple<2x!eir.term">>">
    %26 = eir.cast %25 : !eir<"box<!eir<"tuple<2x!eir.term">>"> to !eir.term {from = !eir<"box<!eir<"tuple<2x!eir.term">>">, to = !eir.term}
    eir.throw(%22, %26, %20) : (!eir.term, !eir.term, !eir.term)
  ^bb7:  // pred: ^bb8
    %27 = eir.trace_capture : !eir.term
    eir.br ^bb6(%27 : !eir.term)
  ^bb8:  // pred: ^bb13
    eir.br ^bb7
  ^bb9(%28: !eir.term):  // pred: ^bb10
    %29 = eir.call @"init:has_message/1"(%16) : (!eir.term) -> !eir.term
    eir.br ^bb1(%29 : !eir.term)
  ^bb10(%30: !eir.term, %31: !eir.term):  // pred: ^bb12
    %32 = eir.constant.int #eir.int<{ value = 2 }>
    %33 = eir.cast %32 : !eir.fixnum to !eir.term {from = !eir.fixnum, to = !eir.term}
    %34 = eir.call @"init:wait/1"(%33) : (!eir.term) -> !eir.term
    eir.br ^bb9(%34 : !eir.term)
  ^bb11(%35: !eir.term):  // pred: ^bb0
    %36 = eir.is_type(%35) {type = !eir<"box<!eir<"tuple<2x!eir.term">>">} : (!eir.term) -> i1
    eir.cond_br %36 : i1, ^bb12, ^bb13(%35 : !eir.term)
  ^bb12:  // pred: ^bb11
    %37 = eir.cast %35 : !eir.term to !eir<"box<!eir<"tuple<2x!eir.term">>"> {from = !eir.term, to = !eir<"box<!eir<"tuple<2x!eir.term">>">}
    %38 = eir.getelementptr %37[] {element = !eir.term, index = 1 : index, pointee = !eir<"tuple<2x!eir.term">} : (!eir<"box<!eir<"tuple<2x!eir.term">>">) -> !eir.ref<!eir.term>
    %39 = eir.load(%38) : (!eir.ref<!eir.term>) -> !eir.term
    %40 = eir.getelementptr %37[] {element = !eir.term, index = 2 : index, pointee = !eir<"tuple<2x!eir.term">} : (!eir<"box<!eir<"tuple<2x!eir.term">>">) -> !eir.ref<!eir.term>
    %41 = eir.load(%40) : (!eir.ref<!eir.term>) -> !eir.term
    eir.br ^bb10(%39, %41 : !eir.term, !eir.term)
  ^bb13(%42: !eir.term):  // pred: ^bb11
    eir.br ^bb8
  }
  eir.func @"init:wait/1"(%arg0: !eir.term) -> !eir.term attributes {personality = @lumen_eh_personality} {
    %0 = eir.receive.start %arg0 : (!eir.term) -> !eir.receive_ref
    br ^bb4(%0 : !eir.receive_ref)
  ^bb1:  // pred: ^bb4
    %1 = eir.receive.message %3 : (!eir.receive_ref) -> !eir.term
    br ^bb5(%1 : !eir.term)
  ^bb2:  // pred: ^bb4
    %c3_i8 = constant 3 : i8
    %2 = cmpi "eq", %4, %c3_i8 : i8
    cond_br %2, ^bb6, ^bb3
  ^bb3:  // pred: ^bb2
    eir.unreachable
  ^bb4(%3: !eir.receive_ref):  // pred: ^bb0
    %4 = eir.receive.wait %3 : (!eir.receive_ref) -> i8
    %c2_i8 = constant 2 : i8
    %5 = cmpi "eq", %4, %c2_i8 : i8
    cond_br %5, ^bb1, ^bb2
  ^bb5(%6: !eir.term):  // pred: ^bb1
    %7 = eir.constant.atom #eir.atom<{ id = 71, value = 'ok' }>
    %8 = eir.cast %7 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    eir.return %8 : !eir.term
  ^bb6:  // pred: ^bb2
    %9 = eir.constant.atom #eir.atom<{ id = 71, value = 'ok' }>
    %10 = eir.cast %9 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    eir.return %10 : !eir.term
  }
  eir.func @"init:has_message/1"(%arg0: !eir.term) -> !eir.term attributes {personality = @lumen_eh_personality} {
    %0 = eir.call @"erlang:self/0"() : () -> !eir.term
    eir.br ^bb1(%0 : !eir.term)
  ^bb1(%1: !eir.term):  // pred: ^bb0
    %2 = eir.constant.atom #eir.atom<{ id = 80, value = 'messages' }>
    %3 = eir.cast %2 : !eir.atom to !eir.term {from = !eir.atom, to = !eir.term}
    %4 = eir.call @"erlang:process_info/2"(%1, %3) : (!eir.term, !eir.term) -> !eir.term
    eir.br ^bb2(%4 : !eir.term)
  ^bb2(%5: !eir.term):  // pred: ^bb1
    %6 = eir.call @"lists:member/2"(%arg0, %5) : (!eir.term, !eir.term) -> !eir.term
    eir.return %6 : !eir.term
  }
}loc("tests/lib/erlang/demonitor_1/with_reference/with_monitor/does_not_flush_existing_message/init.erl":1:1): error: module verification error
error: unexpected error occurred when lowering EIR module

Howdy! Really happy to see an early version of the compiler out there for us to play with!

I just tried to compile an Erlang hello world and got a segfault. Here's the code:

-module(init).
-export([start/0]).

start() ->
    erlang:display(hello_world).

Here's my system info:

OS: Linux Mint 19.3 Cinnamon
Linux kernel: 4.15.0-62-generic
Procesor: Intel Core i7-8550U

And here's my output:

$ /opt/lumen/bin/lumen compile -v ./hello_world.erl
   Compiling ./hello_world.erl
[1]    6558 segmentation fault (core dumped)  /opt/lumen/bin/lumen compile -v ./hello_world.erl

Any other debug logs or something I can generate to help provide more info?

Attempting to wasm-pack build the interpreter-in-browser example errors with the current rust nightly. It appears core::alloc::Alloc no longer exists?

Error:

error[E0432]: unresolved import `core::alloc::Alloc`
  --> /Users/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/dlmalloc-0.1.3/src/lib.rs:21:19
   |
21 | use core::alloc::{Alloc, Layout, AllocErr};
   |                   ^^^^^ no `Alloc` in `alloc`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `dlmalloc`.

Falling back to an older rust nightly seemed to resolve this rustup install nightly-2020-01-02 -> rustup default nightly-2020-01-02

Very new to Rust so apologies if I'm missing something fundamental.

As I mentioned in the call today, I'd like to resolve some outstanding items needed to link up generated code with the runtime.

Items Needed

• [x] Lumen installer generates toolchain with target-specific libraries for linking with generated code
• [x] Linker knows about runtime crates and which to link for each target
• [x] Atom table initialized from constants gathered during compilation at runtime start
• [ ] Codegen generates metadata for scheduler so it knows how to start the compiled application, i.e. it knows what function to call for init:start (See Init)
• [ ] Scheduler needs to know when a process has yielded control due to a request, due to an error being thrown but not caught, or due to process exit (both normally or otherwise). (See Signals)
• [ ] Runtime needs the ability to construct Erlang-style stack traces. We need to store the necessary metadata somewhere, and provide a way to access it from the runtime. (See Traces)
• [ ] Scheduler needs to know how to call into generated code when resuming a process (See Calling Convention, Init)

Init

As a refresher, here's the basic startup routine for an Erlang application:

• VM starts and initializes the runtime
• VM hands control to Erlang by invoking/starting init
• init performs core initialization, reads the boot script containing instructions on how to start the system (i.e. which applications to load/start, in what order, and what functions to call to do so)
• init starts the application_controller
• init walks the boot script, collaborating with the application_controller to load/start applications in the order given; each application is started by starting an application_master for that application.
• each application_master starts its application by invoking the start/2 callback (and others as well)

We will want to mirror this process more or less. In the near term though, we don't have all of the OTP infrastructure in place, we're working with pure Erlang + our runtime, so things differ a bit. Here's more or less what I'm operating on as a starting point:

• Core runtime starts (liblumen_crt - handles calling into the target-specific runtime crate, initializes the atom table)
• Core runtime calls the target-specific runtime entry point (lumen_web/lumen_runtime). This starts the scheduler and performs any other necessary initialization needed by the runtime.
• Scheduler reads the application metadata to obtain the function pointer for the "main" function of the generated code. This would correspond to the init module. The function takes no arguments and is responsible for kicking off execution of the Erlang part of the application.

So given a simple Erlang module:

-module(init).
-export([main/0]).

main() ->
  io:format("~s\n", ["Hello world!"]).

The scheduler would essentially be invoking the function pointer corresponding to the main/0 function. In this case, the function would just print "Hello world!", then signal to the scheduler that the process is exiting normally, which would result in the scheduler shutting down and the program terminating normally.

Down the road, when we start introducing the OTP libraries, we will provide the init module, and it will perform the same kind of startup procedure that init in BEAM does.

I think this provides a nice foundation to build on. The key parts to decide are:

• What metadata is needed in the scheduler
• How does that metadata get generated/stored
• How does the scheduler access it

Signals

In order for linking against the runtime to work at all, we need the ability to signal various conditions between the scheduler and the generated code which needs to branch based on those conditions.

• The scheduler needs to know when control returns from the process code whether it returned due to yielding voluntarily (or due to reduction count/garbage collection), whether the process threw an error that was not caught, or whether the process is exiting (normally or abnormally).
• The generated code needs to know that the scheduler wants it to yield after control returns from a call to the runtime. Likewise, the scheduler may want to signal an exit. When control is yielded to the scheduler, it can do these things without coordination, but when calling into the runtime, the scheduler needs cooperation from the process.
• Beyond just signals, the generated code also needs to be able to monitor/maintain the reduction count on its own. In order to facilitate this, we would use a thread local that both the scheduler and the generated code can check/modify.

My feeling is that we would use a set of thread locals to facilitate these things:

• A thread local for the process signal, an enum which represents the different types of signals
• Thread locals for any signal metadata that is necessary for specific signal types (i.e. an error value for errors that bubble up to the scheduler)
• A thread local for the reduction count

Calling Convention

Related to Signals, is the calling convention between our Rust runtime code, and the generated Erlang code.

If we decide not to use thread locals to signal error conditions/yielding/etc., then the next alternative is to have an ABI/calling convention that allows for effective multi-value returns. In practice that means using a struct with a field to carry the error/status flag, plus one or more fields based on the function's "real" return type. Where this gets ugly is that we already need something like this to communicate function-specific errors, so combining both types of signals into one convention is not ideal.

"Global" signals aside, we can pretty trivially land on an FFI-safe Result/Option equivalent for use at our runtime boundaries. The Option case is actually the easiest, since we can make use of the none value/tag to represent the None variant. The presence of None could then be used to signal that an error occurred, where the error term itself is either stored in the process struct, or in a thread local (similar to errno for example).

Other than that, I think for the near term we'll use the C ABI for all functions - in the future we'll likely use a separate calling convention for Erlang functions, akin to fastcc, but I don't think we have enough information yet on how code will get called, and we can't call from Rust into fastcc code directly, at least not safely.

Traces

To reiterate, there are two kinds of traces:

1. Erlang stack traces, i.e. what you see in error reports from SASL, etc. Displayed in Erlang term format, so easy to parse/understand for users. Matches what was happening from an Erlang perspective, but no relation to the actual thread of execution. Produced when something goes wrong in user code.
2. Native stack traces, i.e. not language-oriented, often shows a lot of frames for code you don't own but was called between frames of your own code. In the worse case, the names are mangled and barely readable. The closest thing to a source of truth about where your application was at when it failed. Produced when shit hits the fan in the runtime itself, or some natively-implemented code fails.

The Erlang code we're compiling generates debug symbols with locations that can be linked back to the original source code. Obtaining a native trace with those symbols is fairly easy (with some work to integrate libbacktrace, or something like it). On the other hand, obtaining an Erlang stack trace is not so easy. There is no easy way to get a trace of locations that correspond only to Erlang code.

Instead we have to construct one somehow. One approach is to maintain our own frame stack that is used solely for Erlang traces, but that isn't ideal - it introduces overhead during execution, and duplicates effort that we'd prefer to avoid duplicating. That said, it has the best chance of mirroring the traces like seen in BEAM.

The approach I would like to try though, is to leverage the debug symbols we generate + libbacktrace. When capturing a trace, we capture a native trace; and when formatting for display, or constructing a term representation, we walk the captured trace and only print symbols for Erlang code.

A mixture of the two approaches could be to have the function prologue push a pointer to the frame metadata on to a stack set aside for Erlang traces. Capturing a trace would take a snapshot of the stack, and formatting/constructing it would follow a similar pattern as the native traces, by resolving the locations in the stack to their corresponding symbols/metadata.

In any case, this is pretty important for getting proper stack traces, but we can probably work around the absence of the functionality in the near term. I'd mostly like to land on a direction though sooner rather than later.

I have no idea if I did this right, and I think there is more work required to getting it to work w/ the AOT compiler, but I figured I'd take a stab at maps:get/2 and maps:get/3 using maps:is_key as an example.

There are invalid escapes sequences according to EIR in the following files in OTP, which Erlang/BEAM deems valid, so EIR's rules need to updated to match:

• ib/dialyzer/src/typer.erl
• lib/common_test/src/unix_telnet.erl
• lib/compiler/src/cerl.erl
• lib/compiler/src/core_scan.erl
• lib/edoc/src/edoc_extract.erl
• lib/edoc/src/edoc_layout.erl
• lib/edoc/src/edoc_lib.erl
• lib/edoc/src/edoc_macros.erl
• lib/edoc/src/edoc_scanner.erl
• lib/edoc/src/edoc_specs.erl
• lib/edoc/src/edoc_tags.erl
• lib/inets/src/http_server/httpd_request.erl
• lib/inets/src/http_server/mod_esi.erl
• lib/inets/src/http_server/mod_range.erl
• lib/kernel/src/group.erl
• lib/kernel/src/os.erl
• lib/kernel/src/user_drv.erl
• lib/megaco/src/engine/megaco_sdp.erl
• lib/observer/src/cdv_bin_cb.erl
• lib/observer/src/cdv_term_cb.erl
• lib/observer/src/crashdump_viewer.erl
• lib/os_mon/src/disksup.erl
• lib/reltool/src/reltool.hrl
• lib/sasl/src/systools_make.erl
• lib/stdlib/src/edlin.erl
• lib/stdlib/src/erl_scan.erl
• lib/stdlib/src/escript.erl
• lib/stdlib/src/io_lib.erl
• lib/stdlib/src/io_lib.erl
• lib/stdlib/src/io_lib_format.erl
• lib/stdlib/src/io_lib_pretty.erl
• lib/tools/src/tags.erl
• lib/xmerl/src/xmerl_regexp.erl

Same error for these two variants:

-module(hello).
-export([hello_world/0]).
hello_world() -> io:fwrite("hello, world\n").

-module(hello).
-export([hello_world/0]).

hello_world() -> erlang:display("hello, world\n").

lawik@MacBook-Pro lumen-testing % lumen compile hello.erl
   Compiling hello.erl
Assertion failed: (impl && "isa<> used on a null type."), function isa, file /Users/paulschoenfelder/src/github.com/bitwalker/llvm-project/mlir/include/mlir/IR/Types.h, line 292.
zsh: abort      lumen compile hello.erl

Resolves #153.

• [x] Implement and test iolist_to_binary/1
• [x] Implement and test iolist_size/1
• [x] Implement and test iolist_to_iovec/1
• [x] Add testing for SubBinary
• [x] Figure out whether to add testing for MatchContext This doesn't seem to be possible yet.

Changelog

Enhancements

• Global local process counter, so getting pids for processes no long needs to go through the Process's Environment.
• Process by pid map is moved to process::local. Processes are always passed as immutable references and interior mutability is used to support global process map trait requirements and to support smaller locks for future work.
• Make all process arenas private to eliminate the needs for Arcs around arenas when it is know the callers would always be in the same process.
  • Don't pass the arenas outside of impl Process to eliminate need for RefCell.
• Don't fake Send and Syn on Process.
  • Switch from im_rc to im so that the map arena is Send.
  • Make heap::Binary Send to override *const u8 in bytes not being Send. heap::Binary are immutable after create, so they can be safely Send even with the raw pointer.
  • Wrap all arenas in Process in Mutex. In most cases there will only be one be accessed by the one scheduler thread. The Mutex is only needed to make Sync derivation happy and potentially during scheduler hand-off.

Incompatible Changes

• Eliminate Environment as anything that would have been in the Environment will not be global to eliminate unnecessary pointer hops.

Bumps crossbeam-channel from 0.4.3 to 0.4.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

The following valid Erlang code will compile, but will cause a runtime error ImmediateOutOfRangeError:

-module(init).
-export([boot/1]).

boot(_) ->
    X = factorial(20),
    erlang:display(X).

-spec factorial(integer()) -> integer().
factorial(0) ->
    1;
factorial(N) when N > 0 ->
    N * factorial(N - 1).

Expected Result

It should display the correct value for factorial(20), which is 2432902008176640000.

Actual Result

It causes a runtime error ImmediateOutOfRangeError:

% firefly compile -C no_default_init --bin smallnum_overflow.erl
   Compiling smallnum_overflow.erl
    Compiled init
      Linker generated executable to _build/firefly/arm64-apple-macosx11.0.0/smallnum_overflow
    Finished built smallnum_overflow in 829ms

$ _build/firefly/arm64-apple-macosx11.0.0/smallnum_overflow
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ImmediateOutOfRangeError',
  runtimes/tiny/src/erlang/mod.rs:82:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
zsh: abort      _build/firefly/arm64-apple-macosx11.0.0/smallnum_overflow

Variations

Changing the first function clause to return a different value will result different behavior:

This one will still cause the runtime error ImmediateOutOfRangeError. It should return 22439560350624250504263050062725120000 for factorial(20).

factorial(0) ->
    2 bsl 62;

This one will not cause a runtime error, but will return a wrong value 0 for factorial(20). The correct value is 44879120701248501008526100125450240000.

factorial(0) ->
    2 bsl 63;

This one will not cause a runtime error, and will return the correct value 89758241402497002017052200250900480000 for factorial(20).

factorial(0) ->
    2 bsl 64;

Environment

• Firefly: develop branch, commit: 323e0ca6 (Sep 12, 2022 UTC)
• macOS Monterey 12.6 (arm64)
• Rust: nightly-2022-08-08
• LLVM: firefly-15.0.0-dev_2022-08-27/clang+llvm-15.0.0-arm64-apple-darwin21.6.0.tar.gz

The following valid Erlang code will not compile. The Firefly compiler will emit an error: "failed to legalize operation 'cir.cast'".

-module(init).
-export([boot/1]).

boot(_Args) -> ok.

a(X, Y, Z) ->
    (X + Y) div Z.

b() ->
    2 bsl 32 - 1.

$ firefly compile -C no_default_init --bin init.erl
   Compiling init.erl
!cir.number
!cir.integer
error: failed to legalize operation 'cir.cast'
   ┌─ init.erl:12:1
   │
12 │ ╭ ╭     (X + Y) div Z.
13 │ │ │
   │ ╰─│^ during generation of mlir associated with this source code
   │   ╰' see current operation: %8 = "cir.cast"(%6#1) {src = [!cir.number]} : (!cir.number) -> !cir.integer

module @init attributes {llvm.data_layout = "e-m:o-i64:64-i128:128-n32:64-S128", llvm.target_triple = "arm64-apple-macosx11.0.0\00"} {
  cir.dispatch_table @init {
    cir.dispatch_entry "boot", 1, @"init:boot/1"
    cir.dispatch_entry "module_info", 1, @"init:module_info/1"
    cir.dispatch_entry "module_info", 0, @"init:module_info/0"
  }
  func @"init:module_info/0"() -> (i1, !cir.term) attributes {personality = @firefly_eh_personality} {

...

Environment

• Firefly: develop branch, commit: 323e0ca6 (Sep 12, 2022 UTC)
• macOS Monterey 12.6 (arm64)
• Rust: nightly-2022-08-08
• LLVM: firefly-15.0.0-dev_2022-08-27/clang+llvm-15.0.0-arm64-apple-darwin21.6.0.tar.gz

The following valid Erlang code will cause the Firefly compiler to get segmentation fault:

-module(init).
-export([boot/1]).

boot(_Args) -> ok.

a(X) when X rem 10 == 0 ->
    ok.

b(Y) when Y div 10 > 2 ->
    ok.

$ firefly compile -C no_default_init --bin init.erl
   Compiling init.erl
zsh: segmentation fault  firefly compile -C no_default_init --bin init.erl

Environment

• Firefly: develop branch, commit: 323e0ca6 (Sep 12, 2022 UTC)
• macOS Monterey 12.6 (arm64)
• Rust: nightly-2022-08-08
• LLVM: firefly-15.0.0-dev_2022-08-27/clang+llvm-15.0.0-arm64-apple-darwin21.6.0.tar.gz

TL;DR

I was recently unable to build Firefly myself and I would love to use a Docker image made by someone who has successfully built it. I might be willing to dedicate more time to get it to build but it would be a lot nicer if I could try using it in a Docker environment to try out some things first.

The long story:

Hi all, I love the work you all are doing and I have high hopes for this project.

Disclaimers: I am new to Rust; I have written only Hello World types of programs in Rust, but I have installed Rust on several development computers in the last few years. I really have a love of Erlang/Elixir and I can see how Firefly would be a great benefit to the BEAM ecosystem so I am taking an interest in this. I think Rust has great potential as well and this is a great application of it.

This time around installing Rust on a new computer, I had no problem at all installing Rust and I was even able to try a few different nightly builds of Rust to try and compile Firefly successfully. In the nightly build that Firefly recommends for most stability (because it matches the version that the CI uses), I had several issues relating to "features" and "core_c_str" or something like that and I even tried learning how Rust "features" work in Cargo and kind of made progress but that's probably a fairly advanced thing to be worrying about for someone with my level of Rust/Cargo knowledge.

Rather than open an issue about the compiler errors and my installation problems, I thought it would be more efficient to ask for a working Docker container because I'm sure several of the project authors are able to compile the project and work on it and I would mostly love to try out the tool and see if I can use it for my use cases. If I am able to do some things with it, I can more easily justify further investigations into Rust and figuring out how to build Firefly by myself.

One of my use cases is compiling Erlang code down to Web Assembly so I think that's the sort of thing that would be doable from a Docker container, since it doesn't have anything to do with cross-compiling to other operating systems and things (which I think can be difficult in Docker sometimes).

Implementing ETS

Erlang Term Storage (ETS) is built on top of two data structures (depending on the options passed to ets:new/2) - an AVL tree in the general case (based on the paper by Adelson-Velski and Landis), and a CA tree [1][2] for ordered sets with write concurrency enabled. For our purposes, we aim to build our ETS implementation on top of WAVL trees [3]. Some interesting references are included below [4][5][6]. Work on the compiler has kept us from building this yet, so this is a great way to get involved with the project!

Goals

• Implement ETS as a library in Rust that can be plugged in to our runtime by writing BIFs that interact with the implementation. Ideally the implementation shouldn't be dependent on runtime specifics like the scheduler, processes, or term representation. If it turns out that such specifics are critical to the implementation though, we can revisit
• Should make use of safe Rust abstractions where possible
• Should provide futures-based APIs for long-running functions (e.g. ets:insert/2 with a list of objects to insert). Functions which are "short enough" don't need to be written as futures, but if implementation is easier that way, it's fine. NOTE: It is essential that these futures do not attempt to hold locks across yield points, if Rust will even allow that in its type system.
• ETS tables should be reference counted, and likely the values they contain as well, so that access by multiple processes is safe, and garbage collection of the tables and their contents can happen naturally.
• While correctness is the most important property, attempts should be made to keep the implementation as performance-sensitive as possible, since ETS is so heavily relied upon.

References

1. A Contention Adapting Approach to Concurrent Ordered Sets, 2018
2. More Scalable Ordered Set for ETS Using Adaptation, 2014
3. WAVL Trees
4. Immutable AVL Trees
5. ERTS AVL Tree
6. ERTS CA Tree