Various small fixes

Allows our project to build with the upgraded zigler

Author: maennchen

guides/01-nifs.md

@@ -152,9 +152,9 @@ end
 
 ## Send
 
-An important mechanism for exporting values out of a NIF is to send it to a process
-ID using the `send` function.  Zigler provides an advanced `beam.send` function which
-will perform this operation for you.
+An important mechanism for exporting values out of a NIF is to send it to a process ID using the
+`send` function. Zigler provides an advanced `beam.send` function which will perform this operation
+for you.
 
 ```elixir
 ~Z"""
@@ -174,8 +174,8 @@ function call.
 
 ## Optional values
 
-You may use optional values as both input and output terms.  Note that the empty optional
-value in elixir is `nil` and the empty optional value in zig is `null`.
+You may use optional values as both input and output terms. Note that the empty optional value in
+elixir is `nil` and the empty optional value in zig is `null`.
 
 ```elixir
 ~Z"""
@@ -198,8 +198,8 @@ end
 
 ## Error Returns
 
-You may use functions which return an error, in which case an `ErlangException` will be
-thrown with the value being the atom representing the error.
+You may use functions which return an error, in which case an `ErlangException` will be thrown with
+the value being the atom representing the error.
 
 ```elixir
 ~Z"""
@@ -223,4 +223,5 @@ end
   This function *does not fail*.
 - for more information on the final options parameter of `get` and `make`, see their respective
   documentation.
-- zigler will translate the hoisted marshalling failures into detailed BEAM exceptions of type `ArgumentError`.
+- zigler will translate the hoisted marshalling failures into detailed BEAM exceptions of type
+  `ArgumentError`.

guides/03-allocators.md

@@ -8,11 +8,12 @@ top* of those allocators.
 
 ## Basic Allocator
 
-The first allocator is `allocator`. This allocator wraps the [nif allocator](https://www.erlang.org/doc/man/erl_nif.html#enif_alloc) 
-provided by the BEAM in the zig allocator interface. You should generally use this allocator over 
-`malloc` because it often saves a syscall by using existing preallocated memory pools, because it 
-allows the VM to track how much memory your NIF is using, and possibly gives better memory placement 
-to avoid cache misses in your execution thread.
+The first allocator is `allocator`. This allocator wraps the [nif
+allocator](https://www.erlang.org/doc/man/erl_nif.html#enif_alloc) provided by the BEAM in the zig
+allocator interface. You should generally use this allocator over `malloc` because it often saves a
+syscall by using existing preallocated memory pools, because it allows the VM to track how much
+memory your NIF is using, and possibly gives better memory placement to avoid cache misses in your
+execution thread.
 
 ```elixir
 ~Z"""
@@ -94,13 +95,13 @@ end
 
 ## Wide Alignment Allocator
 
-Zigler provides a `wide_alignment_allocator` which allows you to allocate memory ranges that have a 
+Zigler provides a `wide_alignment_allocator` which allows you to allocate memory ranges that have a
 higher alignment than the maximum alignment for builtin types. 
 
-> ### memory penalty {: .warning }
+> ### memory penalty {: .warning}
 >
-> Note that using this allocator comes with a memory penalty, so use as a general allocator
-> is not recommended.
+> Note that using this allocator comes with a memory penalty, so use as a general allocator is not
+> recommended.
 
 ```elixir
 ~Z"""
@@ -125,8 +126,9 @@ memory layouts for mixed allocation sizes and the ability to track memory leaks.
 
 The state of the global general purpose allocator is accessible using `beam.allocator_.general_purpose_allocator_instance`
 
-You may also create a custom general purpose allocator instance using `beam.make_general_purpose_allocator_instance`,
-whcih is what happens on a per-nif basis if the nif is checking for leaks.
+You may also create a custom general purpose allocator instance using
+`beam.make_general_purpose_allocator_instance`, whcih is what happens on a per-nif basis if the nif
+is checking for leaks.
 
 ```elixir
 ~Z"""

guides/04-nif_options.md

@@ -183,9 +183,8 @@ end
 
 ## Typespec override
 
-Typespecs generation can be suppressed by setting `spec: false`.
-If you want typespecs for such functions, specify using `@spec` elsewhere
-in your module.
+Typespecs generation can be suppressed by setting `spec: false`. If you want typespecs for such
+functions, specify using `@spec` elsewhere in your module.
 
 For example:
 
@@ -222,5 +221,3 @@ defmodule DisableDoc do
 end
 #module
 ```
-
-

guides/08-module_options.md

@@ -35,9 +35,9 @@ end
 
 ## attributes
 
-Attributes from your module can be used as compile-time constants communicated 
-from elixir.  All attributes of the following types will be automatically 
-available through the `attributes` module import:
+Attributes from your module can be used as compile-time constants communicated from elixir. All
+attributes of the following types will be automatically available through the `attributes` module
+import:
 
 - `integer` (as `comptime int` values)
 - `float` (as `comptime float` values)
@@ -105,9 +105,8 @@ end
 
 ## dump options
 
-Zigler lets you dump various compile-time assets to the console for
-debugging purposes, which can be enabled by setting any given one
-of the following options to `true`:
+Zigler lets you dump various compile-time assets to the console for debugging purposes, which can be
+enabled by setting any given one of the following options to `true`:
 
 - `dump`: dumps the rendered elixir code generated by `use Zig`.
 - `dump_sema`: dumps the json data emitted by the semantic analysis pass.

guides/09-raw_nifs.md

@@ -1,8 +1,8 @@
 # Raw nifs
 
-All of the nifs shown to this point involve zigler constructing an adapter function with
-term marshalling automatically generated.  It is also possible to run a nif without
-doing any of those steps.
+All of the nifs shown to this point involve zigler constructing an adapter function with term
+marshalling automatically generated. It is also possible to run a nif without doing any of those
+steps.
 
 The normal (C) header for a BEAM nif is as follows:
 
@@ -19,7 +19,7 @@ The following two zig function signatures are interpreted as raw nifs:
 
 ## nif options setup
 
-A raw nif MUST contain the `arity` option.  This can be one of:
+A raw nif MUST contain the `arity` option. This can be one of:
 
 - a single integer, representing the desired arity of the nif function
 - a single range, representing a range of arities for the nif function

guides/10-callbacks.md

@@ -1,71 +1,65 @@
 # Module Callbacks
 
-The BEAM provides for a module to have several event-callbacks that are fired 
-when a module is created.  Zigler labels these callbacks in the following way:
+The BEAM provides for a module to have several event-callbacks that are fired when a module is
+created. Zigler labels these callbacks in the following way:
 
 - [`on_load`](#on_load) - when the module is being loaded
 - [`on_upgrade`](#on_upgrade) - when the module is being loaded to replace another module
 - [`on_unload`](#on_unload) - when the module is being purged
 
-These labeled are passed as options to the `use Zig` directive with the
-name of the function to be used as the callback.  All three are optional.
-You may use just the atom to stand a function with the same name, e.g:
-`callbacks: [:on_load]` is shorthand for `callbacks: [on_load: :on_load]`
+These labeled are passed as options to the `use Zig` directive with the name of the function to be
+used as the callback. All three are optional. You may use just the atom to stand a function with the
+same name, e.g: `callbacks: [:on_load]` is shorthand for `callbacks: [on_load: :on_load]`
 
-> ### Callbacks are pub {: .info }
+> ### Callbacks are pub {: .info}
 >
-> Be sure to make your callback functions `pub`.  You do *not* need to
-> add them to the module's `ignore` option.
+> Be sure to make your callback functions `pub`. You do *not* need to add them to the module's
+> `ignore` option.
 
-> ### Context in callbacks {: .info }
-> 
+> ### Context in callbacks {: .info}
+>
 > For all callbacks, the context is set as follows:
-> 
-> - `env`: the `e.ErlNifEnv` value passed to the callback function;
-> - `mode`: `.callback`;
-> - `allocator`: `beam.allocator`;
-> 
-> Thus you should be able to use `beam.get`, `beam.make`, or `beam.send` 
-> with the appropriate context set without extra options.
+- `env`: the `e.ErlNifEnv` value passed to the callback function;
+- `mode`: `.callback`;
+- `allocator`: `beam.allocator`;
+>
+> Thus you should be able to use `beam.get`, `beam.make`, or `beam.send` with the appropriate context
+> set without extra options.
 
 ## on_load
 
 The on_load callback may have one of the following function signatures:
 
 - `fn (?*?*T, U) void`: if the on_load function can never fail.
-- `fn (?*?*T, U) !void`: if the on_load function can fail with an error.
-  The module load integer will reflect the integer value of the error.
-  > #### Zig error integers {: .warning }
-  >
-  > Note that the integer representation of a zig error may change between
-  > compilations.  Translating this integer back to a meaningful value may
-  > be challenging.
-- `fn (?*?*T, U) int`: the on_load function will be considered to fail if
-  the integer value is not `0`.
-- `fn (?*?*T, U) E`: for an `enum` type `E`, the on_load function will be
-  considered to fail if the enum value is not zero.  It's recommended that
-  the enum type `E` be defined as so: `const E = enum{ ok = 0, ...};`
-- `fn (beam.env, ?*?*anyopaque, e.ErlNifTerm) c_int`: this is a 
-  "raw" call that corresponds to the expected signature of a `upgrade` callback.
+- `fn (?*?*T, U) !void`: if the on_load function can fail with an error. The module load integer will
+  reflect the integer value of the error.
+-
+> #### Zig error integers {: .warning}
+>
+> Note that the integer representation of a zig error may change between compilations. Translating
+>   this integer back to a meaningful value may be challenging.
+- `fn (?*?*T, U) int`: the on_load function will be considered to fail if the integer value is not
+  `0`.
+- `fn (?*?*T, U) E`: for an `enum` type `E`, the on_load function will be considered to fail if the
+  enum value is not zero. It's recommended that the enum type `E` be defined as so: `const E = enum{ ok = 0, ...};`
+- `fn (beam.env, ?*?*anyopaque, e.ErlNifTerm) c_int`: this is a "raw" call that corresponds to the
+  expected signature of a `upgrade` callback.
 
 ### on_load Callback types
 
-`T` may be any type at all, which is considered the *private data* of 
-the module.  Any information may be stored in a `*T`, and the double 
-pointer is passed to the callback for the pointer to be communicated 
-to the VM.  The `*T` supplied will be accessible via the `enif_priv_data`
-function
+`T` may be any type at all, which is considered the *private data* of the module. Any information
+may be stored in a `*T`, and the double pointer is passed to the callback for the pointer to be
+communicated to the VM. The `*T` supplied will be accessible via the `enif_priv_data` function
 
-`U` must be a type that can be passed as the first argument of `beam.make`, 
-and the value of `U` will be set by the result of an `__on_load__/0` function 
-defined in the module body.  The result of this function call will be passed
-to the `on_load`
+`U` must be a type that can be passed as the first argument of `beam.make`, and the value of `U`
+will be set by the result of an `__on_load__/0` function defined in the module body. The result of
+this function call will be passed to the `on_load`
 
-> ### on_load and resources {: .info }
+> ### on_load and resources {: .info}
 >
-> The beam nif guide says that resources must be initialized in the `load`
-> callback.  The `on_load` callback must NOT initialize resources.  This
-> is performed in a function that will wrap your `on_load` callback.
+> The beam nif guide says that resources must be initialized in the `load` callback. The `on_load`
+> callback must NOT initialize resources. This is performed in a function that will wrap your
+> `on_load` callback.
 
 #### Example
 
@@ -105,44 +99,41 @@ end
 The on_upgrade callback may have one of the following function signatures:
 
 - `fn (?*?*T, ?*?*U, V) void`: if the on_load function can never fail.
-- `fn (?*?*T, ?*?*U, V) !void`: if the on_load function can fail with an error.
-  The module load integer will reflect the integer value of the error.
-  > #### Zig error integers {: .warning }
-  >
-  > Note that the integer representation of a zig error may change between
-  > compilations.  Translating this integer back to a meaningful value may
-  > be challenging.
-- `fn (?*?*T, ?*?*U, V) int`: the on_load function will be considered to fail if
-  the integer value is not `0`.
-- `fn (?*?*T, ?*?*U, V) E`: for an `enum` type `E`, the on_load function will be
-  considered to fail if the enum value is not zero.  It's recommended that
-  the enum type `E` be defined as so: `const E = enum{ ok = 0, ...};`
-- `fn (beam.env, ?*?*anyopaque, ?*?*anyopaque, e.ErlNifTerm) c_int`: this is a 
-  "raw" call that corresponds to the expected signature of a `upgrade` callback.
+- `fn (?*?*T, ?*?*U, V) !void`: if the on_load function can fail with an error. The module load
+  integer will reflect the integer value of the error.
+-
+> #### Zig error integers {: .warning}
+>
+> Note that the integer representation of a zig error may change between compilations. Translating
+>   this integer back to a meaningful value may be challenging.
+- `fn (?*?*T, ?*?*U, V) int`: the on_load function will be considered to fail if the integer value is
+  not `0`.
+- `fn (?*?*T, ?*?*U, V) E`: for an `enum` type `E`, the on_load function will be considered to fail if
+  the enum value is not zero. It's recommended that the enum type `E` be defined as so: `const E = enum{ ok = 0, ...};`
+- `fn (beam.env, ?*?*anyopaque, ?*?*anyopaque, e.ErlNifTerm) c_int`: this is a "raw" call that
+  corresponds to the expected signature of a `upgrade` callback.
 
 ### on_upgrade Callback types
 
-`T` and `U` may be any type at all, which is considered the *private data* of 
-the module.  Any information may be stored in these pointers, and the double 
-pointer is passed to the callback for the pointer to be communicated 
-to the VM.  The `*U` data supplied will be accessible via the `enif_priv_data`
-function
+`T` and `U` may be any type at all, which is considered the *private data* of the module. Any
+information may be stored in these pointers, and the double pointer is passed to the callback for
+the pointer to be communicated to the VM. The `*U` data supplied will be accessible via the
+`enif_priv_data` function
 
-`V` must be a type that can be passed as the first argument of `beam.make`, 
-and the value of `V` will be set by the result of an `__on_load__/0` function 
-defined in the module body.  The result of this function call will be passed
-to the `on_load`
+`V` must be a type that can be passed as the first argument of `beam.make`, and the value of `V`
+will be set by the result of an `__on_load__/0` function defined in the module body. The result of
+this function call will be passed to the `on_load`
 
-> ### on_upgrade and resources {: .info }
+> ### on_upgrade and resources {: .info}
 >
-> The beam nif guide says that resources must be initialized in the `upgrade`
-> callback.  The `on_upgrade` callback must NOT initialize resources.  This
-> is performed in a function that will wrap your `on_upgrade` callback.
+> The beam nif guide says that resources must be initialized in the `upgrade` callback. The
+> `on_upgrade` callback must NOT initialize resources. This is performed in a function that will wrap
+> your `on_upgrade` callback.
 
 ## on_unload
 
 The on_unload callback may have one of the following function signatures:
 
 - `fn (?*T) void`: if you would like your inbound private data to be typed.
-- `fn (beam.env, ?*anyopaque) void`: this is a "raw" call that corresponds 
-  to the expected signature of a `upgrade` callback.
+- `fn (beam.env, ?*anyopaque) void`: this is a "raw" call that corresponds to the expected signature
+  of a `upgrade` callback.

lib/zig/_c.ex

@@ -51,10 +51,7 @@ defmodule Zig.C do
   defp solve_relative({:system, _} = system, _), do: system
 
   defp solve_relative(file, module_file) do
-    module_file
-    |> Path.dirname()
-    |> Path.join(file)
-    |> Path.expand()
+    Path.expand(file, module_file)
   end
 
   defp normalize_src(file, module_file) when is_binary(file) do

lib/zig/compiler.ex

@@ -137,9 +137,10 @@ defmodule Zig.Compiler do
   # from the :zigler entrypoint for erlang parse transforms, as well as the
   # __before_compile__ entrypoint for Elixir
   def compile(zig_code, code_dir, opts) do
-    zig_code_path = code_dir
-    |> Path.join(".#{opts.module}.zig")
-    |> Path.expand()
+    zig_code_path =
+      code_dir
+      |> Path.join(".#{opts.module}.zig")
+      |> Path.expand()
 
     opts
     |> Map.replace!(:zig_code_path, zig_code_path)

lib/zig/templates/build.zig.eex

@@ -74,7 +74,7 @@ pub fn build(b: *std.Build) void {
         <% {:system, lib} -> %>
     nif.linkSystemLibrary("<%= lib %>", .{});
         <% lib -> %>
-    nif.addObjectFile("<%= lib %>");
+    nif.addObjectFile(.{.cwd_relative = "<%= lib %>"});
       <% end %>
     <% end %>
     <% end %>

lib/zig/type/enum.ex

@@ -82,7 +82,10 @@ defmodule Zig.Type.Enum do
 
   defp accumulate(number, []), do: [number]
   defp accumulate(number, [succ | rest]) when succ == number + 1, do: [number..succ | rest]
-  defp accumulate(number, [succ..last//1 | rest]) when succ == number + 1, do: [number..last | rest]
+
+  defp accumulate(number, [succ..last//1 | rest]) when succ == number + 1,
+    do: [number..last | rest]
+
   defp accumulate(number, noncontiguous), do: [number | noncontiguous]
 
   defp unionize(content) do