3 Commits

Author	SHA1	Message	Date
Benedikt Peetz	5ab2bbb8fd	chore(treewide): Update license header	2024-03-26 20:11:23 +01:00
Benedikt Peetz	3646e4aee8	fix(scripts/renew_copyright_header): Correctly handle shebangs	2024-03-26 19:58:22 +01:00
Benedikt Peetz	eb7a901d09	refactor(treewide): Rework file structure in `src/macros` ... 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.	2024-03-26 17:35:21 +01:00

Renamed from trixy-parser/docs/grammar.ebnf (Browse further)