typos

CONTRIBUTING.md

@@ -6,7 +6,7 @@ Thank you for investing your time into contributing to Capy! All contributions a
 
 First, if you want to know what's needed and wanted, you can always look at the [open issues on GitHub](https://github.com/capy-language/capy/issues). Other than these, more tests are *always* appreciated. There are a lot of features and full test coverage has definetly not been acheived yet. This would be the most appreciated in the `hir_ty` and `codegen` crates.
 
-If you want to try and tackle an existing issue, such as fixing a bug or implementing a feature request, all you have to do is comment on that issue saying that you'd like to try and fix / implement it. This way, it's clear what everyone is working on and no one steps on each other's toes.
+If you want to try and tackle an existing issue, such as fixing a bug or implementing a feature request, all you have to do is comment on that issue saying that you'd like to try and fix / implement it. This way, its clear what everyone is working on and no one steps on each other's toes.
 
 ## How to make a Pull Request
 
@@ -36,17 +36,17 @@ The `parser` crate works in conjuction with the `ast` ([Abstract Syntax Tree](ht
 
 After that, the tree gets processed by the `hir` (High-level Intermediate Representation) crate, which handles indexing and lowering of global variables.
 
-Indexing is essentially just finding out what all the globals are. Global bindings are discovered here. This is done in `index.rs`.
+Indexing is just forming a list of each defined global variable. Global bindings are discovered here. This makes the next steps easier. This is done in [`index.rs`](./crates/hir/src/index.rs).
 
-Lowering is the process of converting the bodies (values) of globals from AST expressions to HIR expressions. HIR expressions contain much more relevant information than a syntax tree and are much easier to work with. Information we don't need is stripped, and the information we *do* need is kept track of neatly. This is done in `bodies.rs`.
+Lowering is the process of converting the values (or bodies) of global variables from AST expressions to HIR expressions. HIR expressions contain much more relevant information than a syntax tree and are much easier to work with. Information we don't need is stripped, and the information we *do* need is kept track of neatly. This is done in [`body.rs`](./crates/hir/src/body.rs).
 
 All those new HIR expressions need to be typed, which is where the `hir_ty` crate comes in. All the crates before this one could've been run in parallel, but now we have to combine all our work across all our different .capy files into one. This crate not only gives the global variables concrete types, but it also does type checking for all expressions everywhere.
 
 Once we've type-checked everything, we can finally begin transforming our HIR into machine code with the `codegen` crate. This crate utilizes [cranelift](https://cranelift.dev/) to generate actual machine code.
 
-The first thing this crate takes care of is evaluating all `comptime { .. }` blocks by JIT compiling them into functions and then calling those functions to get the value. The second thing this crate takes care of is generating the final executable. Under the hood, these two different tasks use the same code for converting HIR into machine instructions (see [`codegen/src/compiler/functions.rs`](./crates/codegen/src/compiler/functions.rs)).
+The first thing this crate takes care of is evaluating all `comptime { .. }` blocks by JIT compiling them into functions and then calling those functions to get the value. The second thing this crate takes care of is generating the final executable. Under the hood, these two different tasks use the same code for converting HIR into machine instructions (see [`codegen/compiler/functions.rs`](./crates/codegen/src/compiler/functions.rs)).
 
-The central nervous system of the codebase is the `capy` crate, which is essentially a CLI crate. But this crate is kind of complex if you're just trying to learn the basics, so I'd recommend looking at the `check_impl` function within the `lib.rs` of the `codegen` crate. It contains the most basic code for compiling multiple .capy files into a binary. Or if you want something even more bare-bones, [`fuzz`](./fuzz/fuzz_targets/main.rs) contains the simplest possible code for transforming source code into typed HIR expressions.
+The central nervous system of the codebase is the `capy` crate, which is essentially a CLI crate. But this crate is kind of complex if you're just trying to learn the basics, so I'd recommend looking at the `tests::check_impl` function within [`codegen/lib.rs`](./crates/codegen/src/lib.rs). It contains the most basic code for compiling multiple .capy files into a binary. Or if you want something even more bare-bones, [`fuzz`](./fuzz/fuzz_targets/main.rs) contains the simplest possible code for transforming source code into typed HIR expressions.
 
 There are a few more helper crates but these aren't too important.