glossary: type signature + typos upgrade (#7776)

* glossary: type signature

Signed-off-by: Anton-4 <17049058+Anton-4@users.noreply.github.com>

* ignore toolchain for typos

Signed-off-by: Anton-4 <17049058+Anton-4@users.noreply.github.com>

* fix typos

* put toolchain file back

---------

Signed-off-by: Anton-4 <17049058+Anton-4@users.noreply.github.com>

Author: Anton-4

.github/workflows/alwayscheck.yml

@@ -23,9 +23,11 @@ jobs:
     steps:
       - uses: actions/checkout@v4
 
-      - run: cargo install typos-cli --version 1.0.11
+      - run: rm rust-toolchain.toml
 
-      - name: do spell check with typos-cli 1.0.11
+      - run: cargo install typos-cli --version 1.32.0
+
+      - name: do spell check with typos-cli 1.32.0
         run: typos
 
       - name: setup Roc
@@ -39,4 +41,4 @@ jobs:
 
       - run: roc version
 
-      - run: roc ./ci/glossary-link-checker.roc
+      - run: roc ./ci/glossary-link-checker.roc

.gitignore

@@ -81,7 +81,7 @@ roc_linux_x86_64.tar.gz
 # macOS .DS_Store files
 .DS_Store
 
-# files geneated when formatting fails
+# files generated when formatting fails
 *.roc-format-failed
 *.roc-format-failed-ast-after
 *.roc-format-failed-ast-before

Glossary.md

@@ -2,7 +2,7 @@ Here you can find definitions for words that are commonly used in the **compiler
 with links to the codebase. Check https://www.roc-lang.org/tutorial if you want to know 
 about general Roc terms. Feel free to ask for a term to be added or add one yourself!
 
-Contributor note: definitons should be roughly ordered like in a tutorial, e.g.
+Contributor note: definitions should be roughly ordered like in a tutorial, e.g.
 Parser should be explained before Canonicalization. 
 
 ## CLI
@@ -132,12 +132,28 @@ Desugaring in the compiler:
 
 ## Type Signature
 
-TODO
+Specifies the type of a variable. For example, the type signature of `Str.concat` is:
+```
+concat : Str, Str -> Str
+```
+Here it specifies `concat` takes two strings as input and produces one as output.
+
+In the compiler, the type signature specified in the source code has priority over the type found by [type inference](#type-inference), although both need to match for your code to compile completely.
+
+Type annotations are basically the same thing as type signatures and both terms are used interchangeably throughout the compiler.
+
+Parsing of type signatures:
+- New compiler: [Parser.zig](src/check/parse/Parser.zig) (search signature)
+- Old compiler: [ast.rs](crates/compiler/parse/src/ast.rs) (search TypeAnnotation)
 
 ## Type Alias
 
 TODO
 
+## Type Variable
+
+TODO
+
 ## Compiler Phase
 
 A compiler phase is a distinct stage in the process the compiler goes through to translate high-level source code into machine code that a computer can execute. Compilers don’t just do this in one big step, they break it down into several phases, each handling a specific task. Some examples of phases: [tokenization](#tokenization), [parsing](#parsing), [code generation](#code-gen),... .

build.zig

@@ -326,7 +326,7 @@ fn llvmPaths(
         };
     }
 
-    // No user specified llvm. Go download it from roc-boostrap.
+    // No user specified llvm. Go download it from roc-bootstrap.
     const raw_triple = target.result.linuxTriple(b.allocator) catch @panic("OOM");
     if (!supported_deps_triples.has(raw_triple)) {
         std.log.err("Target triple({s}) not supported by roc-bootstrap.\n", .{raw_triple});

ci/glossary-link-checker.roc

@@ -30,7 +30,7 @@ main! = |_args|
 
     when full_check_res is
             Ok(_) ->
-                Stdout.line!("Successfuly checked $(List.len(md_links) |> Num.to_str) links.")
+                Stdout.line!("Successfully checked $(List.len(md_links) |> Num.to_str) links.")
             Err(_) ->
                 Err(Exit(1, "Link check failed. Please check the above errors."))
 

crates/docs/src/static/styles.css

@@ -962,8 +962,8 @@ code .keyword.operator {
 }
 
 /* Delimieters */
-samp .delimeter,
-code .delimeter {
+samp .delimiter,
+code .delimiter {
   color: var(--gray);
 }
 

crates/highlight/src/lib.rs

@@ -85,7 +85,7 @@ pub fn highlight(code: &str) -> Vec<String> {
             | Token::Comma
             | Token::Bar
             | Token::Decimal => {
-                buf = push_html_span(buf, current_text, "delimeter");
+                buf = push_html_span(buf, current_text, "delimiter");
             }
             // Types, Tags, and Modules
             Token::UpperIdent | Token::AtSign => {

crates/linker/src/elf.rs

@@ -738,7 +738,7 @@ fn gen_elf_le(
             }
         }
         // To correctly remove the JUMP_SLOT relocations for Roc functions we:
-        //     1. collect the indicies of all of them.
+        //     1. collect the indices of all of them.
         //     2. move them all to the end of the relocation sections.
         //     3. shrink the relocation section to ignore them.
         //     4. update the dynamic section to reflect the shrink as well.

design/editor/editor-ideas.md

@@ -55,8 +55,8 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
 - I think it could be possible to create a minimal reproduction of a program / block of code / code used by a single test. So for a failing unit test I would expect it to extract imports, the platform, types and functions that are necessary to run only that unit test and put them in a standalone roc project. This would be useful for sharing bugs with library+application authors and colleagues, for profiling or debugging with all "clutter" removed.
 - Ability to share program state at a breakpoint with someone else.
 - For debugging we should aim for maximal useful observability. For example Rust's enum values can not be easily viewed in the CodeLLDB debugger, you actually need to call a print method that does pattern matching to be able to view useful information.
-- We previuously discussed recording full traces of programs so they do not have to be re-run multiple times in the debugging process. We should encourage roc developers to experiment with creating debugging representations of this AST+"execution trace", it could lead to some cool stuff.
-- We previuously mentioned showing expression values next to the code. I think when debugging it would be valuable to focus more on these valuas/data. A possible way to do this would be to create scrollable view(without need to jump between files) of inputs and outputs of user defined functions. Clicking on a function could then show the code with the expression values side by side. Having a good overview of how the values change could make it easy to find where exactly things go wrong.
+- We previously discussed recording full traces of programs so they do not have to be re-run multiple times in the debugging process. We should encourage roc developers to experiment with creating debugging representations of this AST+"execution trace", it could lead to some cool stuff.
+- We previously mentioned showing expression values next to the code. I think when debugging it would be valuable to focus more on these valuas/data. A possible way to do this would be to create scrollable view(without need to jump between files) of inputs and outputs of user defined functions. Clicking on a function could then show the code with the expression values side by side. Having a good overview of how the values change could make it easy to find where exactly things go wrong.
 
 - (Machine learning) algorithms to extract and show useful information from debug values.
 - Ability to mark e.g. a specific record field for tracking(filter out the noise) that is being repeatedly updated throughout the program.
@@ -147,7 +147,7 @@ e.g. you have a test `calculate_sum_test` that only uses the function `add`, whe
 - open google/github/duckduckgo search for error...
 - show editor plugins for library X
 - commands to control log filtering
-- collaps all arms of when
+- collapse all arms of when
 - "complex" filtered search:  search for all occurrences of `"#` but ignore all like `"#,`
 - color this debug print orange
 - remove unused imports

design/language/Abilities.md

@@ -348,7 +348,7 @@ isNotEq : Dict k v, Dict k v -> Bool
 In this `Eq { isEq, isNotEq }` declaration, I'm saying that `isEq` and `isNotEq` are functions already in scope. I could also choose different names using record literal syntax, e.g. `Eq { isEq: dictIsEq, isNotEq: dictIsNotEq }` - the relevant part is that I'm specifying the names of the functions (which must also be in scope) which specify how `Eq` for Dict should work.
 
 Now that I've specified this, when I use `==` on two `Dict` values, this `isEq` function will get run instead of the default `==` implementation. This solves [Problem #3](#problem-3-decoders-are-still-hard-to-learn)!
-I can also write something like has `Num` and provide the relevant functions to obtain a unit-ful number type - which solves [Problem #2](#problem-2-custom-number-types-cant-use-arithmetic-operators).
+I can also write something like has `Num` and provide the relevant functions to obtain a unit-ful number type, which solves [Problem #2](#problem-2-custom-number-types-cant-use-arithmetic-operators).
 
 ### Default Abilities for Newtypes