This might be a big diff, but I _hope_ that it does not change much
functionally (hopefully it changes nothing generation specific).
What has changed?
-----------------
- I had to merge the three crates into one, to allow `macros` to impl
functions on Types defined in `parser`.
- As mentioned in the point above, the conversion function are now
inherent to the type they convert (i. e. `r#type.to_rust()` instead of
`type_to_rust(r#type)`).
- The conversion function have been sorted, by what they convert to:
- `to_rust()` converts a type to be used in rust *host* code.
- `to_c()` converts a type to be used in c *host* code.
- `to_auxiliary_c()` converts a type to be used in c *auxiliary*
code.
- The top-most `generate` method of `TrixyConfig` now returns a
`FileTree` instead of writing the files directly. The `FileTree` can
still be materialize with the `materialize` method. But this change
facilitates moving non-generation focused code out of the `generate`
method.
What is the difference between _host_ and _auxiliary_ code?
-----------------------------------------------------------
Auxiliary code is always written in the language it is generated for. So
auxiliary code for c would be written in c (or at least in a subset of c),
as it represents c header files.
Host code is always written in rust. This is the code that is
responsible for implementing the actual ffi stuff. In our case these are
the `extern "C"` functions and the types, defined in trixy.
The rust host code is generating the native rust representations of
these types.
This error should only ever be raised, when we encountered a bug.
This change notifies the user, that the situation is rather likely to be
a bug and that this should be reported.
Errors were contextualized by finding their index in the source file.
This method is extremely flaky, as it _hopes_ that the line is not
spread over multiple lines.
The new method actually uses the span to calculate a matched line and
thus avoids any issues related to the actual position of the line in the
source file.
Notably these diverge from rust, by requiring argument names. This is a
deliberate design decision, as it help users to guess what's going to be
passed into their callback.
Previously we actually supported parsing doc comments (`///`), but
replacing them before parsing allows for simplifications in the lexer.
Precisely, that means that we can add support for attributes without
having to maintain the doc comment parser.
This only adds this as nix module. So running `nix fmt` will now format
all files under the repo root.
If you want to run this as non-nix user feel free to take a look at the
generated `treefmt.toml`.
The old implementation tried to provide rust types in c—like the
result or option types. This implementation now removes this source of
complexity by ensuring, that these types are unwrapped on the rust->c
boundary.
This first commit changes the header files to conform to the new api.
This changes two important things:
- Firstly it renames the `nasp` keyword to `mod`:
This change removes the not required deviation from rust.
- Secondly it removes the semicolon after an enumeration or structure
declaration, which is pointless in these positions.
These are implemented right now by simply casting the generic arguments
to void pointers and providing a `type_id` field in every struct
denoting the original type.
This implementation, whilst being extremely unwieldy to work with on
the c side, also fails in a lot of fundamental ways:
1. The `type_id` enum *can* never really support user defined
types because we would already need it to provide the c to rust
value conversion.
2. Even without custom user types the type conversion is extremely
hard to correctly implement in a somewhat performant way: A vector
passed from c code to rust would need to completely reallocated
*one element at a time*. And this only works if the c side has
correctly cast the void pointer to the vectors data before accessing
it, as any other way would have lead to possible unaligned data
(which the rust side had to account for).
3. The c api is just simply bad in this state:
You have to always look at the Trixy file to even be able to deal
with the data the api returns (that is: There is no mention of
a results generics in the c header). Additionally the question
arises if these types should even be leaked into the c code because
than c just becomes a worse version of rust, which undermines the
whole reason of providing a c api in the first place.
One way to fix all these issues would be to change the way generics are
handled by using unions instead of the void pointer and trying to avoid
leaking these rust types in c as far as possible.
This approach would require a lot less binding code (both on the c and
rust side), but also would make the rust based c-header-gen-code harder,
as it would then be required to turn a `Vec<String>` to a `char **` (and
obviously a whole wrapper struct with size and string length), whilst
turning a `Vec<char>` to a `char*` differentiating it from a `string_t`.
Benedikt Peetz