1## Contributing 2 3### Start a Project Using Zig 4 5One of the best ways you can contribute to Zig is to start using it for a 6personal project. Here are some great examples: 7 8 * [Oxid](https://github.com/dbandstra/oxid) - arcade style game 9 * [TM35-Metronome](https://github.com/TM35-Metronome) - tools for modifying and randomizing Pokémon games 10 * [River](https://github.com/ifreund/river/) - a dynamic tiling wayland compositor 11 12More examples can be found on the 13[Community Projects Wiki](https://github.com/ziglang/zig/wiki/Community-Projects). 14 15Without fail, these projects lead to discovering bugs and helping flesh out use 16cases, which lead to further design iterations of Zig. Importantly, each issue 17found this way comes with real world motivations, so it is easy to explain 18your reasoning behind proposals and feature requests. 19 20Ideally, such a project will help you to learn new skills and add something 21to your personal portfolio at the same time. 22 23### Spread the Word 24 25Another way to contribute is to write about Zig, or speak about Zig at a 26conference, or do either of those things for your project which uses Zig. 27Here are some examples: 28 29 * [Iterative Replacement of C with Zig](http://tiehuis.github.io/blog/zig1.html) 30 * [The Right Tool for the Right Job: Redis Modules & Zig](https://www.youtube.com/watch?v=eCHM8-_poZY) 31 * [Writing a small ray tracer in Rust and Zig](https://nelari.us/post/raytracer_with_rust_and_zig/) 32 33Zig is a brand new language, with no advertising budget. Word of mouth is the 34only way people find out about the project, and the more people hear about it, 35the more people will use it, and the better chance we have to take over the 36world. 37 38### Finding Contributor Friendly Issues 39 40Please note that issues labeled 41[Proposal](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3Aproposal) 42but do not also have the 43[Accepted](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3Aaccepted) 44label are still under consideration, and efforts to implement such a proposal 45have a high risk of being wasted. If you are interested in a proposal which is 46still under consideration, please express your interest in the issue tracker, 47providing extra insights and considerations that others have not yet expressed. 48The most highly regarded argument in such a discussion is a real world use case. 49 50The issue label 51[Contributor Friendly](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3A%22contributor+friendly%22) 52exists to help you find issues that are **limited in scope and/or 53knowledge of Zig internals.** 54 55### Editing Source Code 56 57First, build the Stage 1 compiler as described in 58[Building Zig From Source](https://github.com/ziglang/zig/wiki/Building-Zig-From-Source). 59 60Zig locates lib files relative to executable path by searching up the 61filesystem tree for a sub-path of `lib/zig/std/std.zig` or `lib/std/std.zig`. 62Typically the former is an install and the latter a git working tree which 63contains the build directory. 64 65During development it is not necessary to perform installs when modifying 66stage1 or userland sources and in fact it is faster and simpler to run, 67test and debug from a git working tree. 68 69- `make` is typically sufficient to build zig during development iterations. 70- `make install` performs a build __and__ install. 71- `msbuild -p:Configuration=Release INSTALL.vcxproj` on Windows performs a 72build and install. To avoid install, pass cmake option `-DZIG_SKIP_INSTALL_LIB_FILES=ON`. 73 74To test changes, do the following from the build directory: 75 761. Run `make` (on POSIX) or 77 `msbuild -p:Configuration=Release INSTALL.vcxproj` (on Windows). 782. `$BUILD_DIR/zig build test` (on POSIX) or 79 `$BUILD_DIR/Release\zig.exe build test` (on Windows). 80 81That runs the whole test suite, which does a lot of extra testing that you 82likely won't always need, and can take upwards of 1 hour. This is what the 83CI server runs when you make a pull request. (Note: actually it runs a few 84more tests; keep reading.) 85 86To save time, you can add the `--help` option to the `zig build` command and 87see what options are available. One of the most helpful ones is 88`-Dskip-release`. Adding this option to the command in step 2 above will take 89the time down from around 2 hours to about 6 minutes, and this is a good 90enough amount of testing before making a pull request. 91 92Another example is choosing a different set of things to test. For example, 93`test-std` instead of `test` will only run the standard library tests, and 94not the other ones. Combining this suggestion with the previous one, you could 95do this: 96 97`$BUILD_DIR/bin/zig build test-std -Dskip-release` (on POSIX) or 98`$BUILD_DIR/Release\zig.exe build test-std -Dskip-release` (on Windows). 99 100This will run only the standard library tests, in debug mode only, for all 101targets (it will cross-compile the tests for non-native targets but not run 102them). 103 104When making changes to the compiler source code, the most helpful test step to 105run is `test-behavior`. When editing documentation it is `docs`. You can find 106this information and more in the `--help` menu. 107 108#### Testing Changes to std lib 109 110To quickly test a change to a file in the standard library, you can run zig test and specify a custom lib directory with the follow command-line argument. 111 112```bash 113./build/zig test lib/std/fmt.zig --zig-lib-dir lib --main-pkg-path lib/std 114``` 115 116#### Testing Non-Native Architectures with QEMU 117 118The Linux CI server additionally has qemu installed and sets `-fqemu`. 119This provides test coverage for, e.g. aarch64 even on x86_64 machines. It's 120recommended for Linux users to install qemu and enable this testing option 121when editing the standard library or anything related to a non-native 122architecture. 123 124##### glibc 125 126Testing foreign architectures with dynamically linked glibc is one step trickier. 127This requires enabling `--glibc-runtimes /path/to/glibc/multi/install/glibcs`. 128This path is obtained by building glibc for multiple architectures. This 129process for me took an entire day to complete and takes up 65 GiB on my hard 130drive. The CI server does not provide this test coverage. Instructions for 131producing this path can be found 132[on the wiki](https://github.com/ziglang/zig/wiki/Updating-libc#glibc). 133Just the part with `build-many-glibcs.py`. 134 135It's understood that most contributors will not have these tests enabled. 136 137#### Testing Windows from a Linux Machine with Wine 138 139When developing on Linux, another option is available to you: `-fwine`. 140This will enable running behavior tests and std lib tests with Wine. It's 141recommended for Linux users to install Wine and enable this testing option 142when editing the standard library or anything Windows-related. 143 144#### Testing WebAssembly using wasmtime 145 146If you have [wasmtime](https://wasmtime.dev/) installed, take advantage of the 147`-fwasmtime` flag which will enable running WASI behavior tests and std 148lib tests. It's recommended for all users to install wasmtime and enable this 149testing option when editing the standard library and especially anything 150WebAssembly-related. 151 152#### Improving Translate-C 153 154Please read the [Editing Source Code](#editing-source-code) section as a 155prerequisite to this one. 156 157`translate-c` is a feature provided by Zig that converts C source code into 158Zig source code. It powers the `zig translate-c` command as well as 159[@cImport](https://ziglang.org/documentation/master/#cImport), allowing Zig 160code to not only take advantage of function prototypes defined in .h files, 161but also `static inline` functions written in C, and even some macros. 162 163This feature works by using libclang API to parse and semantically analyze 164C/C++ files, and then based on the provided AST and type information, 165generating Zig AST, and finally using the mechanisms of `zig fmt` to render 166the Zig AST to a file. 167 168The relevant tests for this feature are: 169 170 * `test/run_translated_c.zig` - each test case is C code with a `main` function. The C code 171 is translated into Zig code, compiled, and run, and tests that the expected output is the 172 same, and that the program exits cleanly. This kind of test coverage is preferred, when 173 possible, because it makes sure that the resulting Zig code is actually viable. 174 175 * `test/stage1/behavior/translate_c_macros.zig` - each test case consists of a Zig test 176 which checks that the relevant macros in `test/stage1/behavior/translate_c_macros.h`. 177 have the correct values. Macros have to be tested separately since they are expanded by 178 Clang in `run_translated_c` tests. 179 180 * `test/translate_c.zig` - each test case is C code, with a list of expected strings which 181 must be found in the resulting Zig code. This kind of test is more precise in what it 182 measures, but does not provide test coverage of whether the resulting Zig code is valid. 183 184This feature is self-hosted, even though Zig is not fully self-hosted yet. In the Zig source 185repo, we maintain a C API on top of Clang's C++ API: 186 187 * `src/zig_clang.h` - the C API that we maintain on top of Clang's C++ API. This 188 file does not include any Clang's C++ headers. Instead, C types and C enums are defined 189 here. 190 191 * `src/zig_clang.cpp` - a lightweight wrapper that fulfills the C API on top of the 192 C++ API. It takes advantage of `static_assert` to make sure we get compile errors when 193 Clang's C++ API changes. This one file necessarily does include Clang's C++ headers, which 194 makes it the slowest-to-compile source file in all of Zig's codebase. 195 196 * `src/clang.zig` - the Zig equivalent of `src/zig_clang.h`. This is a manually 197 maintained list of types and functions that are ABI-compatible with the Clang C API we 198 maintain. In theory this could be generated by running translate-c on `src/zig_clang.h`, 199 but that would introduce a dependency cycle, since we are using this file to implement 200 translate-c. 201 202Finally, the actual source code for the translate-c feature is 203`src/translate_c.zig`. This code uses the Clang C API exposed by 204`src/clang.zig`, and produces Zig AST. 205 206The steps for contributing to translate-c look like this: 207 208 1. Identify a test case you want to improve. Add it as a run-translated-c test 209 case (usually preferable), or as a translate-c test case. 210 211 2. Edit `src/translate_c.zig` to improve the behavior. 212 213 3. Run the relevant tests: `./zig build test-run-translated-c test-translate-c` 214